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Als führender Fachverlag für Elektronik schreiben wir nicht nur für 
Computer-Profis und -Hobbyisten, sondern auch für Leute, 
die meinen, „für mich ist das alles viel zu kompliziert“. Wir informieren 
kompetent, verständlich und regelmäßig. Ihr Weg zum Computer sollte deshalb 
über uns führen. Wie? Dafür zwei Beispiele: 
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\Vorvvort 


Komplexere Aufgaben erfor- 
dern leistungsfähigere Lösun- 
gen. Diese allgemeingültige 
Aussage trifft wie für alle Le- 
bensbereiche ganz besonders 
auch für die Elektronik zu. 


Auf die Mikroprozessortechnik 
übertragen heißt das, daß den 
wachsenden Anforderungen an 
Systeme auch entsprechend 
leistungsfähige Konzepte ent- 
gegengestellt werden müssen. 


Wie steigert man die Leistung 
von Mikrocomputersystemen? 
Schnellere Verarbeitung und 
damit höherer Durchsatz be- 
deutet Verwendung von Hoch- 
geschwindigkeits-Bauelemen- 
ten, die teuer und nicht einfach 
zu handhaben sind. Ein breites 
Datenwort, also der Schritt vom 
16- zum 32- oder sogar 64-Bit- 
Prozessor, bedeutet eine Erhö- 
hung der IC-Komplexität, die 
ebenfalls nicht unproblematisch 
ist. 





Die Lösung, bei der heute ver- 
fügbare Techniken und Produk- 
te Verwendung finden, liegt im 
Multi-Mikrocomputer-Konzept. 


Systeme mit mehreren Prozes- 
soren sind natürlich auch nicht 
leicht zu konzipieren und reali- 
sieren. Hilfestellung sowie An- 
regungen dazu bieten die in 
dem vorliegenden Heft zusam- 
mengefaßten Beiträge. 
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Hermann Schmid 


Multi-Mikroprozessor-Systeme 


1. Teil: Grundlagen 


Konfigurationen mit mehreren Mikroprozessoren 
haben seit einiger Zeit große Bedeutung erlangt. In 
vielen Anwendungsbereichen sind Konfigurationen, 
bei denen die Verarbeitungsleistung auf mehrere Pro- 
zessoren verteilt ist, Konzepten mit nur einem lei- 
stungsfähigen Zentralrechner überlegen. Vorteile sind 
beispielsweise hohe Flexibilität und geringere Störan- 
fälligkeit. Die ELEKTRONIK hat in den letzten Jahren 
schon häufig über Mehrprozessorsysteme berichtet 
und die Konzepte einzelner praktisch ausgeführter 


1 Warum Multi-Mikroprozessor-Systeme? 


Kleine, preiswerte, aber trotzdem leistungsfähige Digi- 
talrechner bieten heute Lösungsmöglichkeiten für viele 
Probleme: 
© Energieeinsparungim Haushalt, in Fabrikationsstätten, 

Automobilen usw. 

@ Produktionseinrichtungen mit höherer Effizienz, z. B. 
für Lebensmittel, Textilien usw. 

© Systeme für Kommunikation, Ausbildung, Unterhal- 
tung usw. 

Eine Möglichkeit, die Leistung von Computern zu 
steigern, ist, deren Arbeitsgeschwindigkeit zu erhöhen. 
Allerdings erfordern schnelle Schaltelemente, beispiels- 
weise in ECL-Technik aufgebaut, höhere Betriebslei- 
stung und eignen sich zudem nicht zur Integration in 
LSI-Strukturen. Die Implementierung eines typischen 
Minicomputers mit Bauelementen mittlerer Integra- 
tionsdichte erfordert nicht nur ein breites Spektrum 
unterschiedlicher Typen, sondern auch viele Platinen 
und einige tausend elektrische Verbindungen (Bild 1). 

Dagegen kann man bei einem Multi-Mikroprozessor- 
System (MMPS) hohe Leistung bei Verwendung identi- 
scher LSI-Bausteine erreichen. Es handelt sich dabei 
jeweils um komplette Prozessoren mit CPU, Speicher 
sowie E/A-Einheit, die mit relativ geringer Taktfrequenz 
arbeiten. Diese Prozessoren können untereinander in 
einem einfachen Leitungspaar verbunden werden, 
wodurch der Aufwand sehr gering ist. Außerdem benö- 
tigt ein MMPS nur eine geringe Anzahl Platinen und 


Systemlösungen beschrieben. In der mit diesem Bei- 
trag beginnenden Aufsatzreihe soll die Technik der 
Multi-Mikroprozessor-Systeme umfassend und syste- 
matisch dargestellt werden. Moderne Entwicklungen, 
beispielsweise die kürzlich vorgestellten 32-Bit-Pro- 
zessoren, werden auch berücksichtigt. Der erste Teil 
der Beitragsreihe befaßt sich mit den Grundlagen der 
Mehrprozessorsysteme. Es werden insbesondere die 
Begriffe definiert und der Zusammenhang zwischen 
ihnen dargestellt. 


Stecker. Daraus ergibt sich die sehr hohe Hardware- 
Ökonomie eines MMPS. 

Das MMPS bietet außerdem architektonische Flexibi- 
lität und Erweiterbarkeit. Mit einer einzigen Architektur 
(die aber sorgfältig konzipiert sein sollte) kann eine 
große Anzahl von Systemen implementiert werden, 
unabhängig von den jeweiligen Anforderungen an 
Durchsatz, Speicher- oder E/A-Kapazität. 

Zukünftig werden an erster Stelle die Anforderungen 
für digitale Prozessor-Hardware die Zuverlässigkeit, 
Wartbarkeit, Überlebensfähigkeit, Sicherheit sowie 
geringe Kosten während des Lebenszyklus sein. Erfüllt 
werden diese Forderungen von fehlertoleranten Mehr- 
prozessorsystemen. 

Wartbarkeit ist die Fähigkeit, Fehler zu entdecken, zu 
isolieren und zu beseitigen, so daß das System nach 
einer Fehlfunktion weiterarbeiten kann. Der Aufwand 
für die Wartung von technischen Einrichtungen (bei- 
spielsweise Automobilen, Flugzeugen, Computern 
usw.) hat sich zu einem signifikanten Prozentsatz der 
Gesamtkosten entwickelt. Zukünftige Geräte müssen in 
der Lage sein, auch nach Auftreten von Fehlern zu 
funktionieren. Mit der Verfügbarkeit von preiswerter 
digitaler Hardware fallen die Kosten für redundante 
Prozessoren im Vergleich zu Reparatur- und Ausfall- 
kosten nicht mehr ins Gewicht. 

Es gibt einige Gründe, warum MMPS noch nicht so 
häufig verwendet werden: 
® Einchip-Prozessoren mit ausreichender CPU-, Spei- 

cher- und E/A-Leistung werden jetzt erst verfügbar. 
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© Bis jetzt gibt es nur wenige erprobte Techniken für die 
Kommunikation, Prioritätsdecodierung und Arbitra- 
tion zwischen den Prozessoren. 

@® Methoden, Werkzeuge und Betriebssysteme für die 
Softwareentwicklung sind noch nicht ausgereift und 
daher kommerziell noch nicht verfügbar. 


2 Welche Multi-Mikroprozessor-Systeme gibt es? 


Ein MMPS soll hier als ein Verarbeitungssystem defi- 
niert werden, welches: 
© mindestens zwei uPs, die jeweils aus einer CPU, einem 

lokalen Speicher sowie lokalen E/A-Einheiten besteht; 
@ die Möglichkeit bietet, daß alle Einzelprozessoren mit- 

einander kommunizieren können, indem sie auf einen 

Globalspeicher (der zentral oder verteilt angeordnet 

sein kann) zugreifen; 
© die Möglichkeit zum Datenaustausch zwischen allen 

Prozessoren über eine oder mehrerere System- oder 

Globalbusse bietet; 
© alle Prozessoren am gleichen physikalischen Ort zu- 

sammenfaßt. 

Viele Multiprozessorkonfigurationen wurden bereits 
entwickelt, allerdings bildeten die meisten Mini- und 
Großcomputer [1]. Anderson [2] hat die verschiedenen 
Architekturen folgendermaßen klassifiziert: 

1. SIMD-Systeme (Single Instruction, Multiple Data), 
2. Bi 
— Array-Prozessoren 
— Assoziative Prozessoren 
. MIND-Systeme (Multiple Instruction, Multiple Data), 
2. B& 
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Bild 1. Die Verbindungen, die bei einem konventionellen 
Einzelprozessor- bzw. Multiprozessorsystemen notwendig 
sind, wenn ein serieller Bus verwendet wird 











— Verteilte Multiprozessorsysteme (geographisch ver- 

teilt). 

— Zusammengefaßte Multiprozessorsysteme (am glei- 

chen Ort). 

Zusammengefaßte Multiprozessorsysteme lassen sich 

wiederum folgendermaßen einteilen: 

a) Mehrere CPUs teilen sich einen gemeinsamen Spei- 
cher (Bild 2a). Diese Version ist sehr uneffizient und 
wird daher nicht näher erläutert. 

b) Mehrere Prozessoren (CPU, Speicher und E/A) an 
einem gemeinsamen Bus (Bild 2b). Diese Version ist 
am leichtesten realisierbar und wird daher heute sehr 
oft verwendet. 

c) Hierarchische Systeme in drei Ebenen (Bild 2c). Diese 
Version kann als Erweiterung von b) zur Realisierung 
größerer Systeme angesehen werden. 

d) Prozessor- oder Kreuzschienen-Netzwerke, mit denen 
N Verarbeitungsmodule mit N Speichermodulen über 
Kreuzschienenschalter verbunden sind (Bild 2d). 
Diese Version eignet sich für die Implementierung 
von Systemen mit Großrechnerleistung. 

Theoretisch läßt sich jedes zusammengefaßte MMPS 
zu einem fehlertoleranten Verarbeitungssystem machen, 
indem eine dynamische Rekonfiguration hinzugefügt 
wird, nämlich die Möglichkeit: 


® Fehler zu entdecken und zu isolieren, die Beschädi- 
gung einzuschätzen und diese der Steuereinheit mitzu- 
teilen; 

@ den fehlerhaften Prozessor durch einen Ersatz im dyna- 
misch redundanten System auszutauschen; 

@ die Tasks (Software-Prozesse) in einer vorherbestimm- 
ten Weise neu zu verteilen; 

®@ der direkten Neuverteilung durch zentrale oder ver- 
teilte Steuereinheit. 


Obwohl die Notwendigkeit für fehlertolerante Com- 
puter allgemein anerkannt wird [3] und dies immer als 
endgültiges Entwicklungsziel für Multiprozessor-Kon- 
zepte sein sollte, beschäftigt sich dieser Beitrag nur mit 
Systemen, bei denen jeder Prozessor einer speziellen 
Aufgabe zugeteilt ist. Außerdem sollen hier nur solche 
Systeme beschrieben werden, bei denen komplette Pro- 
zessoren über einen parallelen Systembus miteinander 
kommunizieren, wie das in Bild 2b dargestellt ist. 


3 Multi-Mikroprozessor-Systembusse 


Der Systembus ist das Rückgrat eines jeden Prozessor- 
systemes. Durch diesen ist nicht nur die Hardware, 
Software und die Kommunikationsprotokolle zur Ver- 
knüpfung der Prozessoren oder der gemeinsamen Res- 
sourcen mit dem Bus definiert, sondern auch standar- 
disiert. Es gibt viele Buskonfigurationen, z. B. seriell/ 
parallel, einfach/redundant usw., wobei jede Lösung 
einen Kompromiß zwischen Leistung, Kosten sowie 
dem Grad der Verknüpfung zwischen den Prozessoren 
darstellt. Allgemein kann man sagen, daß serielle Busse 
geringe Kosten verursachen (es ist nur ein Leitungspaar 


erforderlich), eine lose Kopplung und eine geringe 
Datentransferrate bieten. Daher werden sie vornehmlich 
für die Verbindung über längere Distanzen (>1 m) in 
verteilten Systemen benutzt. Im Gegensatz dazu haben 
Parallelbusse mit mehreren Leitungen eine festere 
Kopplung, ermöglichen höhere Datenraten, sind aber teu- 
rer. Serielle Busse erfordern wesentlich aufwendigere 
Kommunikationsprotokolle, beispielsweise HDLC oder 
X.25, die an anderer Stelle dieser Reihe beschrieben 
werden. Hier sollen nur Systeme mit parallelen Bussen, 
wie Multibus, Z-Bus oder S-100-Bus, behandelt werden. 

Die Parallelbusse für Systeme mit einem oder mehre- 
ren Prozessoren sind normalerweise in einer Party-Line- 
Konfiguration implementiert, indem alle Steckan- 
schlüsse auf der Verdrahtungsrückwand des Computers 
parallel miteinander verbunden werden. Die Gesamt- 
länge der Leitungen und ihre charakteristische Impe- 
danz bestimmen die Grenzen der Übertragungsrate und 
Transportverzögerungen. Derzeit verwendete Mikropro- 
zessorsystem-Busse, wie Multibus, Z-Bus oder S-100, 
haben zwischen 50 und 100 Leitungen. 

Adressen- und Datenleitungen werden manchmal im 
Multiplex geschaltet, wie das beim Z-Bus der Fall ist. 
Anderenfalls besitzt jedes Bit oder jede Stromzuführung 
eine eigene Leitung. Die Implementierung des Steuerbe- 
reiches eines Busses ist problematischer, weil dadurch 
die Betriebsweise des Gesamtsystems bestimmt wird. 
Die Entscheidung, welche Steuerleitungen benutzt wer- 
den sollen, wie sie zusammenzufassen, zu codieren, zu 
multiplexen und implementieren sind, ist eine Aufgabe, 
die außerordentlich viel Erfahrung erfordert, insbeson- 
dere wenn das System Multiprozessor-Betrieb unterstüt- 
zen muß. 

Ein Systembus für ein Multiprozessor-Steuersystem 
muß zusätzlich zum konventionellen Datentransfer und 
den Steuerleitungen Einrichtungen zur Steuerung fol- 
gender Funktionen enthalten: 


® Anforderung des Busses oder einer anderen gemeinsa- 
men Ressource; 

© Decodierung der Priorität aller Partner (bis zu 64); 

® Arbitrierung der Anforderungen mit hoher Geschwin- 
digkeit; 

© Übergabe der Steuerung an neuen Bus-Master (Bus- 
Grant); 

© Adressierung einer jeden Datenquelle im System; 

© Rekonfiguration des Systems oder Wiederaufnahme 
der Erledigung von Tasks; 

© Überwachung und Test aller Busoperationen. 


Die meisten vorhandenen Mikroprozessor-System- 
busse bieten nur sehr begrenzte Möglichkeiten zur Mul- 
tiprozessor-Unterstützung. Der Multibus unterstützt bei- 
spielsweise nur die Daisy-Chain-Prioritätsdecodierung/ 
Arbitration von bis zu vier Partnern sowie nur einfache 
Bus-Request/Grant-Protokolle. Dagegen umfaßt der neue 
Backplane-Busstandard, der von dem IEEE Computer 
Society Microprocessor Standard Committee (P896) vor- 
bereitet wird, die meisten der oben aufgeführten Punkte. 















jeder Prozessor 
besitzt CPU, 
Speicher und E/A 





besitzt CPU, 


jeder Prozessor 
Speicher und E/A 


M 
| 


EI I 


m separate 
Speicher- 
module 


NxM 
Kreuz 
schienen- 


schalter 








N 
Bild 2. Die vier grundlegenden Multiprozessor-Architekturen, a) 
n CPUs greifen auf einen gemeinsamen Speicher zu, b) n Prozes- 
soren benutzen einen gemeinsamen Bus im Zeitmultiplex, c) 


hierarchisches System auf drei Ebenen, d) Kreuzschienen-Netz- 
werk 








4 Speicherkonfigurationen 


Typ, Größe und Lage des Speichers haben großen 
Einfluß auf die Eigenschaften des MMPS. Der Gesichts- 
punkt bei der Auswahl und der Lokalisierung des Spei- 
chers muß immer so sein, daß die Datenmenge, die 
zwischen den Prozessoren über den Systembus transfe- 
riert werden muß, möglichst klein ist. Die wichtigsten 
Fragen sind dabei: 
® Lokaler oder gemeinsamer Speicher? Oder beides? 
© Wieviel lokaler Speicher, welcher Typ und welche 

Zugriffsarten? 
® Wie sollen die Speicher für einfache Adressierung 

organisiert sein? 

Alle diese Erwägungen repräsentieren architektoni- 
sche Gesichtspunkte, die unter Berücksichtigung 
moderner Hardware- und Softwareentwicklungen gese- 
hen werden müssen. Beispielsweise ist ein lokaler Spei- 
cher nicht mehr so kostenintensiv, wie es vor nicht allzu 
langer Zeit war, weil mittlerweile preiswerte monolithi- 
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sche Prozessoren zur Verfügung stehen, die auf dem 
Chip einen Speicher besitzen. 


4.1 Gemeinsamer Speicher für gemeinsame Variable 


In früheren Multiprozessorsystemen (Bild 2a) teilten 
sich mehrere CPUs einen Speicher in dem die lokalen 
und globalen Variablen abgelegt waren. Der Speicher 
wurde damit zur Engpaßstelle des Gesamtsytems. Neu- 
erdings speichert man nur die gemeinsamen Variablen 
in gemeinsamen Speichern. Dieser Speicher übernimmt 
eine Funktion wie ein öffentliches „Schwarzes Brett“, 
durch das jeder Zugang zu allen Informationen hat. 
Zugriffskonflikte sind weitgehend ausgeschlossen, weil 
keine lokalen Variablen gespeichert sind. 


4.2 Lokaler Speicher für lokale Variable 


Jede CPU muß ihren eigenen Speicher zum Ablegen 
von Anwenderprogrammen und lokalen Variablen 
haben, so daß sich über eine Instruktion oder lokale 
Variable unabhängig vom Systembus oder dem gemein- 
samen Speicher verfügen kann. Das führt dazu, daß 
nicht nur die Operationen der CPU schneller sind, son- 
dern beläßt den Systembus und den gemeinsamen Spei- 
cher der Kommunikation zwischen den Prozessoren. 
Die Menge von Daten, die im gemeinsamen Speicher 
abgelegt ist und über den Systembus transferiert werden 
muß, ist stark reduziert. 

Der Zugriff auf lokale Speicher vom Systembus kann 
folgendermaßen erfolgen: 
© Über Interrupt-Anfrage an die lokale CPU, die den 

Systembus an den lokalen Bus nach Ausführung der 
laufenden Instruktion anbindet. Die anfragende CPU 
muß während dieser Zeit warten, was eine Verzöge- 
rung von einigen 100 us bei längeren Multiplikations- 
oder Divisions-Instruktionen bedeutet. Außerdem ist, 
während die andere GPU auf den Speicher zugreift, die 
lokale CPU untätig. 


© Über direkten Speicherzugriff oder Busaufruf der loka- 
len CPU, die auch den Systembus mit dem lokalen Bus 
verbindet, allerdings in diesem Fall schneller. Die 
anfragende CPU muß nur warten, bis die lokale CPU 
den gerade laufenden Maschinenzyklus beendet hat, 
der bei den Hochleistungs-uPs nur einige us beträgt 
(2,5 us beim Z8000). Trotzdem ist die lokale CPU untä- 
tig, während die externe CPU auf den lokalen Speicher 
zugreift. 

© Direkt und ohne VerzögerungaufRAMs mit zwei Ports. 
Weder die anfragende noch die lokale CPU verschwen- 
den Zeit, in der sie aufeinander warten müssen. Das ist 
die ideale Lösung. 


4.3 Lokale „Mailboxes“ für die Kommunikation 


Ein gemeinsamer Speicherbereich kann entfallen, 
wenn jeder Prozessor eine lokale „Mailbox‘ besitzt 
(Bild 3), die einem individuellen „Schwarzen Brett“ für 
die Mitteilung allgemein verfügbarer Variablen für die 
anderen Partner entspricht. Ausschließlich die lokale 
CPU kann in ihre Mailbox schreiben, alle anderen kön- 
nen nur daraus lesen. Dadurch wird auch verhindert, 
daß fehlerhaft arbeitende Prozessoren die Daten in der 
Mailbox zerstören können oder den Bus durch dauernde 
Schreibaktionen verstopfen. Die lokale Mailbox hat 
einen weiteren Vorteil. Falls sie ausfällt, ist nur ein Teil 
des Systems unbenutzbar. Dagegen fällt das gesamte 
System aus, wenn eine globale Mailbox versagt. 


4.4 Dual-Port-RAM 


Die Eigenschaften des Gesamtsystems verbessern sich 
erheblich, wenn die lokale Mailbox mit einem Dual- 
Port-RAM implementiert ist. 

In diesem Fall kann die lokale CPU in die Mailbox 
schreiben, während zur gleichen Zeit eine andere CPU 
aus dieser lesen kann. Aus diesem Grund muß die 
andere CPU nicht auf den Zugriff zur Mailbox warten. 
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Bild 3. Multiprozessorsystem mit gemeinsamen Bus im zeitlichen Multiplex. Jeder Prozessor hat eine lokale 
Mailbox, auf die direkt vom Systembus aus zugegriffen werden kann 











Der Einplatinen-Computer SBC-86/12 von Intel [4] bietet 
ein Quasi-Dual-Port-RAM (Adressen- und Datenleitun- 
gen werden zwischen zwei Benutzern umgeschaltet). 
Die ersten echten Dual-Port-RAMs mit nennenswerter 
Größe sind mittlerweile kommerziell verfügbar. Der 
Baustein MC68340 von Motorola ist seit 1982 erhält- 
lich [5]. 


4.5 Memory-Mapping 


Damit jede Mailbox für alle CPUs im System leicht 
erreichbar ist, müssen die lokalen Speicher eines jeden 
Prozessors innerhalb eines globalen Speicherbereiches 
gelegt werden. Als Beispiel soll das in Bild 4 dargestellte 
System dieses Verfahren zeigen. Der 64-KByte-Speicher 
eines jeden der acht Prozessoren wurde aus dem 512- 
KByte-Speicher zugewiesen. Eine 3-Bit-Adresse 
(A21...A23) wählt das gewünschte Segment aus. Jeder 
64-K-Speicherbereich ist in folgende Segmente aufge- 
teilt: der Programm-, der lokale Variablen- und der glo- 
bale Variablenbereich, wobei letzterer die Mailbox dar- 
stellt. Nur die lokale GPU kann dort hineinschreiben. 
Um die Mailbox eines anderen Prozessors zu adressie- 
ren, muß die lesende CPU die drei höherwertigen Bits zu 
ihrer lokalen Adresse hinzufügen. 


5 Operationen des Multiprozessorsystems 


Ein Multiprozessorsystem unterscheidet sich von 
einer Anordnung mehrerer einzelner Prozessoren wie 
ein Arbeitsteam von einer Gruppe individueller Arbei- 
ter. Das Ziel eines Arbeitsteams ist die Ausführung der 
Gesamtaufgabe innerhalb kürzester Zeit, der Gesichts- 
punkt für einen individuellen Arbeiter ist die Fertigstel- 
lung seiner spezifischen Aufgabe mit geringstem Zeit- 
aufwand. Die Benutzung von einzelnen Arbeitern oder 
Prozessoren ist daher ineffizient, insbesondere wenn der 
Umfang der Aufgaben stark unterschiedlich ist, oder 
wenn eine Aufgabenlösung das Resultat oder Teillösun- 
gen anderer Aufgaben erfordert. Im Gegensatz dazu 
arbeiten Teams oder Multiprozessorsysteme effizient, 
weil deren einzelne Mitglieder miteinander kommuni- 
zieren, kooperieren und die Arbeitsbelastung aufteilen. 
Im einzelnen benötigt ein Multiprozessorsystem daher: 


© Einen Systembus zum Transfer von Adressen-, Daten- 
und Steuerinformationen zwischen jeweils zwei Pro- 
zessoren 

@ Prioritäts-Decodierungs/Arbitrations-Hard- und -Soft- 
ware zur Steuerung des Zugriffs zu allgemeinen 
Ressourcen wie Speicher, E/A-Einheiten, Systembus 
usw. 

® Ein Betriebssystem zur Steuerung, Verwaltung und 
zum zeitlich planmäßigen Ablauf von Verarbeitungs- 
aufgaben sowie der Benutzung der Ressourcen. Außer- 
dem muß festgelegt werden, wer wen zu welchem 
Zeitpunkt steuert. 
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Bild 4. Der Speicher eines jeden Prozessors besitzt einen Global- 
bzw. E/A-Bereich 











5.1 Datentransfer zwischen Prozessoren 


Der Grund einer jeden Kommunikation zwischen Pro- 
zessoren ist der Austausch von Daten. Die Transferope- 
ration belastet sowohl die Datenquelle als auch den 
Empfänger. Die Zeit, die für die Transferoperation erfor- 
derlich ist, gehört zum „Overhead“ und reduziert die 
Gesamteffizienz des Systems. Aus diesem Grund sind 
für ein Hochleistungs-Multiprozessorsystem eine mög- 
lichst hohe Transferrate und geringe Verzögerungszeiten 
erforderlich. 

Daten können über einen parallelen Bus mit einfachen 
Schreib-/Lese-E/A-Operationen und vier Schritten trans- 
feriert werden: 
® Einleitung des Transfers mit Hard- oder Software; 
® Auswahl von Quelle/Empfänger durch die entspre- 

chenden Adressierungssignale; 
® Abfrage von Quelle/Empfänger zur Ein-/Ausgabe der 

Daten von/auf den Bus; 

@ Weiterführung des Prozesses. 

Die Datenrate (Wörter/s) und die Anzahl der Datenlei- 
tungen legt die Datentransferkapazität des Systembusses 
fest und damit den Schlüsselfaktor, der die Leistung des 
Gesamtsystems bestimmt. Die MMPS-Leistung wird 
außerdem durch die Bus-Zugriffszeit, die Anwahlverzö- 
gerung eines Partners, die Antwortzeit eines Partners 
usw. beeinflußt. Alle diese Faktoren werden im dritten 
Beitrag dieser Reihe näher diskutiert. 


5.2 Transfer der Steuerung zwischen den Prozessoren 


Bei dem MMPS, der in Bild 2b dargestellt ist, muß 
jeder Prozessor mit jedem anderen über den Systembus 
kommunizieren. Allerdings kann nur ein Prozessor den 
Systembus steuern. Daraus folgt, daß die verschiedenen 
Prozessoren beim Zugriff zum Systembus in Konkurrenz 
stehen. Diese Wettbewerbssituation muß durch Zuwei- 
sung in vorher festgelegte Prioritäten durch einen Arbi- 
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ter gelöst werden. Bevorzugt bei Zuweisung ist der 
jeweils „derzeitige Master“. Um einen Prozessor zum 
Bus-Master zu machen, ist es erforderlich, daß er die 
Steuerung des Busses übertragen bekommt. Dafür sind 
die folgenden Schritte erforderlich: 
®@ Aufstellung von Prioritäten durch 
- räumliche Decodierung (Daisy Chain), 
— Zuweisung eines Prioritätcodes für jeden Prozessor; 
— umlaufende Priorität (der Prozessor, der als letzter 
die Steuerung übernommen hat, bekommt die 
geringste Priorität); 
® Initialisierung von Bus-Anfragen (eine Sequenz von 
Mikroprogramm-Schritten), um 
— zu überprüfen, ob der Systembus gerade benutzt wird 
und die Anfrage abzubrechen, wenn dies der Fall ist; 
- die Bus-Request-Leitung zu aktivieren, damit die 
Anfrage allen anderen signalisiert wird, 
—- zu warten, daß die Anfrage entschieden, bewilligt 
oder zurückgewiesen wird; 


@ Entscheidung über Anfragen lokal oder zentral durch 

— Identifizierung des Anfragenden über seine räumli- 
che Position oder den Code (Vektor), 

— Vergleich des seriellen oder parallelen Prioritäts- 
Codes des Anfragers, 

— Freigabe der Einheit mit der höchsten Priorität und 
Sperren aller anderen durch Aussenden eines Bus- 
Bewilligungssignals zum neuen Master. 

Der neue Master kann nun den Systembus steuern. 
Allerdings ist es das Ziel, daß Daten zwischen dem 
Master und anderen globalen Ressourcen (Speicher 
usw.) transferiert werden. Deshalb muß der Partner zu 
seinem lokalen Bus Zugriff erlauben. Wenn die globalen 
Variablen in einem Dual-Port-RAM gespeichert sind, ist 
dieser Zugriff dauernd erlaubt. Der neue Master erzeugt 
ganz einfach die entsprechende Globaladresse und führt 
eine E/A-Operation aus. In derzeit üblichen Multipro- 
zessorsystemen werden Interrupt-, DMA- oder durch 
Bus-Request gesteuerter Zugriff auf den lokalen Spei- 
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cher benutzt, weil Dual-Port-RAMs noch nicht in genü- 
gender Zahl verfügbar sind. 

Das heißt, daß der Zugriff auf einen lokalen Speicher 
die Übernahme der Steuerung der lokalen Ressourcen 
des Partners bedeutet. Dazu sind die folgenden Schritte 
erforderlich (Bild 5): 
© Auswahl des Partners durch Ausgabe der Adresse 

(3 Bit), die wiederum einen Interrupt, DMA- oder Bus- 

Request für die CPU des Partners erzeugt. 
© Start eines Zählers, für die Zeitbegrenzung, wenn der 

Partner den Zugriff nicht in einer vorher festgelegten 

Periode bewilligt. 
© Der Partner führt die laufende Instruktion bzw. den 

Maschinenzyklus aus, schaltet sich vom lokalen Bus ab 

und gibt danach das Busfreigabe-Signal aus. 
® Das Busfreigabe-Signal gibt dem neuen Master die 

Steuerung der lokalen Ressourcen des Partners und 

erlaubt die gewünschte Datentransfer-Operationen. 

Die Entscheidung, welche dieser Funktionen in der 
Hardware oder in der Software implementiert sein sol- 
len, ob die verschiedenen Operationen lokal vom Pro- 
zessor oder zentral von einer System-Steuereinheit aus- 
geführt werden sollen, hängt von den Entwicklungs- 
richtlinien ab, die durch die Anwendung sowie die 
verfügbare Hard- oder Software beeinflußt werden. 


6 Implementierung des 
Prioritäts-Decodierers/Arbiters 


Die Zuweisung von Prioritäten zu allen Prozessoren 
im System sowie die gerechte Zuteilung bei Zugriffsan- 
fragen für den Systembus sind die wichtigsten Gesichts- 
punkte eines Multiprozessorsystems. Eine Anzahl ver- 
schiedener Techniken wurde zur Implementierung die- 
ses Systems bereits benutzt, wobei jede Lösung unter 
dem Gesichtspunkt der Hardware-Komplexität sowie 
des Kosten-Leistungsverhältnisses gesehen werden 
muß. Die Techniken unterscheiden sich im Decodierer/ 
Arbiter: 
© Anordnung: zentral oder lokal (bei jedem Prozessor); 
© Typ: Anfrage-/Bewilligungslogik, Daisy-Chain-Logik, 

Parallel-Komparator. 
© Anfrage-Identifikation: Anfrage-/Bewilligungsleitun- 

gen, räumliche Lage, Code. 

Die Techniken mit der größten Leistung sind, wie 
üblich, diejenigen mit der höchsten Komplexität und 
den höchsten Kosten. Sie fordern außerdem einen 
umfangreichen Software-Support. Die Leistungsparame- 
ter eines Decodierers/Arbiters sind folgende: 
© die Wartezeit: Periode zwischen Anfrage und Beginn 

der Ausführung; 
© die Ausführungszeit: die erforderliche Zeit zur Ausfüh- 

rung der Anfrage, der Zuteilung und der Übertragung 
der Steuerung. 


Die folgenden Beschreibungen zeigen, wie verschie- 
dene existierende Mikroprozessorbusse die Funktionen 
der Prioritätscodierung und Abitration implementieren. 


6.1 Der Daisy-Chain-Decodierer/Arbiter 
des ZBI-Busses 


Der ZBI-Bus von Zilog ist eine 96polige Backplane- 
Verbindung, mit der Einzel- und Multiprozessorsysteme 
unterstützt werden [6]. Neben den 32 im Multiplexbe- 
trieb benutzten Adreß/Daten- sowie 15 Stromversor- 
gungsleitungen besitzt der Bus insgesamt 41 Steuerlei- 
tungen, mit denen folgende Funktionen unterstützt 
werden: BE 
© konventionelle Datentransfers: AS*, DS*, R/W, W/LW; 
© Interrupt auf drei Ebenen: INT1*, INT2*, INT3*, IE1, 

IE2, IE3, I01, IO2, 103; u 
® Systemsteuerung: MCLK, BCLK, N/S, STO, ST1, ST2, 

ST3, STOP*, RESET*; 
® direkter Speicherzugriff: BAI*, BAO*, BUSREQ*; 
© Aufteilung der Resourcen: MMAI*, MMAO*, 

MMREQ*, MMST*; 
® Multiprozessor-Steuerung: CAI*, CAO*, GPUREQ*, 

CAVAIL; 

@ Fehlerprüfung: PO, P1, P2, P3, PE*, PWRBAD*. 

Die Steuerleitungen für den direkten Speicherzugriff, 
die Aufteilung der Ressourcen sowie die Multiprozes- 
sorsteuerung ermöglichen den Aufbau eines dezentrali- 
sierten Priorität-Decodierers/Arbiters mit Daisy-Chain- 
Konzept für unterschiedliche Systemtypen. Die Steuer- 
leitungen für den direkten Speicherzugriff sind vor- 
nehmlich für Systeme mit einem Master und mehrere 
Peripherieeinheiten in einer Prioritätskette gedacht. Die 
Steuersignale für die Aufteilung der Ressourcen und 
Multiprozessor-Steuerung sind beide für Mehrprozes- 
sor-Konfigurationen. Die Steuerleitungen für die Vertei- 
lung der Ressourcen sorgen dafür, daß immer nur ein 
Zugriff auf eine Ressource möglich ist. Die Multiprozes- 
sorsteuerung unterstützt ein aufwendigeres Protokoll 
von gegenseitigem Ausschluß und Transfer der Steue- 
rung. 

Die Steuerleitungen für die Aufteilung der Resourcen 
(MMREQ*, MMAI*, MMAO*, MMST*) ermöglichen 
den Aufbau von Multiprozessorkonfigurationen wie sie 
in Bild 6a dargestellt sind [7]. In dieser Konfiguration 
sind alle Prozessoren des Systems mit den Leitungen 
MMAI* und MMAO* verkettet. Low-Pegel auf der Lei- 
tung MMAI* (als Antwort auf einen MMREQ*) pflanzt 
durch die Kette fort, bis er den anfragenden Prozessor 
erreicht. Die Kombination von Low-Pegel auf MMREQ* 
und einem High-Pegel auf MMAI* identifiziert den 
neuen Bus-Master. Bevor ein Prozessor einen MMREQ* 
ausgeben kann, muß er die MMREQ*-Leitung abfragen. 
Wenn diese Leitung auf Low-Pegel liegt (busy), wird die 
Anfrage später wiederholt, oder sie entfällt. Wenn die 
Leitung auf High-Pegel liegt (frei) wird MMREQ* auf 
Low geschaltet. Die Anfrage war erst erfolgreich, wenn 
MMAI* nach einer vorherbestimmten Verzögerungszeit 
auch auf Low-Pegel geht. Anderenfalls wird die Anfrage 
abgebrochen. 

Der eigentliche Decodierer/Arbiter besteht aus einer 
Kombination der in Bild 6b gezeigten Logikschaltung, 
der Z8000-Schaltung mit den Signalen ul* und uO* 
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sowie der Software mit den vier Befehlen MREQ, MRES, 
MSET und MBIT. Die vier Gatter und der Inverter bilden 
nicht nur die Prioritätssignale nach, sie formen auch die 
vier ZBI-Bus-Signale zu den zwei Multiprozessorsigna- 
len des Z8000 ul* uO* um. 


6.2 Der S-100-Parallel-Prioritätsdecodierer/Arbiter 


Der S-100-Bus ist ein 100poliges Rückwandverbin- 
dungssystem, das für Einzel- und Multiprozessorkonfi- 
gurationen geeignet ist. Die 100 Busleitungen untertei- 
len sich in 16 Datenleitungen, 16 oder 24 Adressenlei- 
tungen, 10 Stromzuführungen, der Rest sind Steuerlei- 
tungen. 

Der neue S-100-Bus, wie er vom IEEE Computer 
Society Standard Commitee (IEEE Tasks P692.1) defi- 
niert worden ist, enthält eine parallele Prioritäts-Deco- 
dierung/Arbitration mit hoher Geschwindigkeit für Mul- 


HOLD*-Leitung sowie ein pHOLDA (hold acknow- 
ledge). Jeder der Master muß einen Decodierer/Arbiter 
(Bild 7) sowie einen eigenen Prioritätscode besitzen. Die 
Arbeitsweise der Schaltungen und das dazu gehörige 
Protokoll, das in [8] beschrieben ist, können folgender- 
maßen zusammengefaßt werden: 


@ HOLD* darf nur benutzt werden, wenn es noch nicht 
signalisiert ist und pHLDA auf Low-Potential liegt; 
© HOLD* muß entfallen, wenn pHLDA auf High schaltet 
und wenn ein anderer Controller höhere Priorität be- 
kommt; 

@ HOLD* muß entfallen, wenn der Controller den Bus 
nicht länger benötigt; 

© Die Priorität muß zugewiesen werden, wenn HOLD* 
auftritt, und muß bis zur nächsten fallenden Flanke 
von PHLDA zugewiesen bleiben; 

® Die Prioritätsebene muß für den Benutzer aus- 
zuwählen sein (über Schalter) und auf den Bus- 











tiprozessorsysteme mit bis zu 16 Mastern [8]. Der Bus leitungen über Open-Kollektor-Treiber anliegen 
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Bild 6. Eine Busanfrage von einem Prozessor wird 
über eine ODER-Verknüpfung auf die BUSRQ-Lei- 
tung gegeben und dazu benutzt, den Daisy-Chain- 
Prioritäts-Decodierer zu initialisieren. Der Prozessor, 
bei dem das Signal MMRQ* Low und das MMAO*- 
Signal High ist, bekommt die Steuerung des Busses 
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Bild 7. Der parallele Prioritätsdecodierer/Arbiter des S-100-Busses 
setzt die Prioritätsebenen mit vier Schaltern, die auf die Signale von 
DMAO0*...DMA3* wirken und vergleicht seine eigene Prioritätsebene 
mit der auf dem Bus 
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© Das höchstwertige Bit der Prioritätsebene (erscheint auf 
DMA3*) muß mit der angegebenen Priorität verglichen 
werden. Falls die Leitung auf Low liegt, aber nicht 
durch den derzeitigen Master, müssen alle niedrigwer- 
tigen Prioritätsbits entfernt werden. Ähnlich müssen 
die Bits DMA2*, DMA1* und DMAO0* überprüft wer- 
den und mögliche niedrigwertige Konflikt-Bits entfernt 
werden; 

© Wenn keine der Leitungen auf Low gelegt sind, außer 
denen, die von dem derzeitigen Master auf Low 
geschaltet sind, hat dieser Master nach einer entspre- 
chenden Einschwingzeit die höchste Priorität und 
kann den Bus übernehmen, wenn pHLDA auf High 
umschaltet 

® Die Implementation der Logik muß so ausgeführt sein, 
daß die Einschwingzeit der Arbitrationsschaltung 
sowie des Busses zwischen dem HOLD*-Signal und 
dem Ansteigen von pHLDA liegt. 


7 Software für Multiprozessorsysteme 


Derzeit sind es erst relativ wenige Multi-Mikroprozes- 
sorsysteme in Betrieb. Ein Grund dafür ist, daß die 
Hardware, die am besten dafür geeignet ist, und zwar 
Einchip-Computer, die speziell für Mehrprozessorbe- 
trieb konzipiert sind, zur Zeit noch nicht auf dem Markt 
erhältlich sind. Der andere Grund ist, daß die Systemar- 
chitekturen noch entwickelt werden. Der Hauptgrund 
ist allerdings, daß nur sehr wenig Multiprozessor-Sup- 
port sowie Anwender-Software erhältlich sind. Das Vor- 
handensein von zuverlässiger Unterstützungs-Software 
ist aber eine Vorbedingung für jede Entwicklungsarbeit. 
Das Aufkommen von strukturierten höheren Program- 
miersprachen (PASCAL, ADA usw.) sowie der modula- 
ren Betriebssysteme (RMX/86 usw.) für parallele und 
Multi-Tasking-Programmierung, verspricht, daß Lösun- 
gen nicht mehr lange auf sich warten lassen [9, 10, 11, 
12]. 


7.1 Höhere Programmiersprachen 


Reduzierung des Zeit- und Kostenaufwandes bei der 
Entwicklung von Anwenderprogrammen ist nur eines 
der Vorteile von höheren Programmiersprachen. Wichti- 
ger ist die Aufteilung des Problems in immer kleinere 
Module nach der „Top-down-Methode“ sowie die Pro- 
zeduren zur Kommunikation zwischen den Modulen. 
Diese Strukturen und Prozeduren sind die Basis für die 
Entwicklung jeglicher Soft- und Hardware. Diese wer- 
den insbesondere wichtig, wenn Betriebssysteme für 
Multi-Tasking- und Multi-Processing-Konzepte entwik- 
kelt werden. 


7.2 Multiprozessor-Betriebssysteme 


Die Funktion eines Betriebssystems ist die Verwal- 
tung, Zuweisung und Vergabe der Ressourcen wie CPU- 
Zeit, Speicher sowie E/A-Einheiten. Ein Trend bei 


Betriebssystemen führt zu verstärkter Modularisierung. 
Sie bestehen aus einem Kern und einer Gruppe von 
Modulen, jeweils eines für jede Ressource im System. 
Betriebssysteme sind normalerweise als Software ausge- 
führt (auf Band oder Platte) oder als Firmware auf einem 
ROM. Moderne Entwicklungen bei Mikroprozessoren 
implementieren den Betriebssystemkern innerhalb der 
Hardware, direkt auf den CPU-Chip [13]. Das wird bei 
zukünftigen Multiprozessor-Entwicklungen Vorteile 
bringen, denn: 
® es erfordert strengere Kommunikationsprozeduren 
zwischen den Modulen; 
® es ermöglicht fertige Softwarelösungen und damit 
geringere Belastung des Softwareentwicklers; 
® es räumt einen Teil der Hindernisse für die Akzeptie- 
rung von Multiprozessorsystemen aus dem Weg. 
Obwohl Betriebssysteme für Multiprozessorpro- 
gramme solchen für Multi-Tasking-Programme sehr 
ähnlich sind, sind sie etwas komplizierter. Ein Punkt 
dabei ist, daß die gesamte Kommunikation zwischen 
den Modulen die Soft- und Hardwareverknüpfungen 
berücksichtigen muß. Ein weiterer Faktor zur Kompli- 
zierung ist die Koordination zwischen den Prozessoren, 
insbesondere in der Startphase, im leistungssparenden 
Betrieb (Power down) oder während oder bzw. nach 
Fehlern. Außerdem erfordern die meisten Anwendun- 
gen eine Art Synchronisation zwischen den Prozesso- 
ren. Weitere Schwierigkeiten treten bei dynamisch 
rekonfigurierbaren und fehlertoleraten Systemen auf. 
Eine Voraussetzung für solche Systeme ist ein Selbsttest 
und die Fähigkeit zur Fehlerisolierung. Ein Betriebssy- 
stem für ein Multiprozessorkonzept muß alle diese 
Funktionen enthalten. 
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Hermann Schmid 


Multi-Mikroprozessor-Systeme 


2. Teil: Technischer Stand 


Der 1. Teil dieser Aufsatzreihe beschäftigte sich mit 
den Grundlagen, die zunächst kurz zusammengefaßt 
dargestellt werden sollen: MIMD-Architekturen (Mul- 
tiple Instruction, Multiple Data) werden in vier Gruppen 
aufgeteilt: a) Mehrere CPUs teilen sich einen gemein- 
samen Speicher, b) mehrere Prozessoren arbeiten auf 
einem gemeinsamen Bus, c) hierarchische Systeme, 
d) Kreuzschienen-Netzwerke. Jede Gruppe kann mit 
verschiedenen Bus- und Speichertypen sowie Konfi- 
gurationen und Operationen implementiert werden, 


1 Am weitesten verbreitet: 
Gemeinsamer Bus im Time-Share-Betrieb 


Von den verschiedenen Klassen und Kategorien der 
Multi-Mikroprozessor-Architekturen, die bereits aufge- 
zählt wurden, findet man die Gruppe 2b vom Typ 
MMPS-1 [10] heute am häufigsten. Diese Gruppe, die im 
allgemeinen als Architektur mit gemeinsamen Bus im 
Time-Share-Betrieb (TSCB - Time Shared Common Bus) 
bezeichnet wird, kann entweder mit einem parallelen 
oder seriellen Bus implementiert werden, außerdem mit 
oder ohne gemeinsamen Globalspeicher. Derzeit übliche 
TSCB-Systemimplementationen verwenden in den mei- 
sten Fällen einen Parallelbus (Bild 1). 

In existierenden TSCB-Systemen werden N unabhän- 
gige Mikrocomputer entweder durch einen parallelen 
(Multibus, Versabus usw.) oder seriellen Bus verbun- 
den. Jeder dieser Mikrocomputer (8 oder 16 Bit) ist eine 
physikalische Einheit — eine Platine oder ein Chip -, 
besitzt eine CPU mit entsprechender Steuerung, einen 
lokalen Bus, lokalen oder globalen Speicher, serielle 
sowie parallele E/A-Einheiten, Zähler/Zeitgeber, ein 
Systembus-Interface mit Prioritätscodierungs- und Bus- 
arbitrationsschaltungen. Wie viele Prozessoren können 
auf diese Weise verbunden werden? Die Zahl N hängt 
von vielen Parametern ab, wie das später beschrieben 
werden wird, sie ist aber im allgemeinen kleiner als 
acht. 

Der Systembus ist eine allgemeine Ressource, die von 
allen angeschlossenen Einheiten benutzt wird. Nur ein 
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um verschiedene Ebenen der Verkopplung bzw. Lei- 
stungsstufen zu erreichen. Die Systemeffizienz ist 
sehr stark abhängig von den Techniken, die für Priori- 
tätscodierung und Busarbitration, Datentransfer 
sowie Steuerung der einzelnen Prozessoren verwen- 
det werden. Außerdem ist es die Software — die Pro- 
grammiersprachen sowie die Möglichkeiten des 
Betriebssystems -, die die gesamte Architektur, die 
Implementationen, Operationen und Merkmale be- 
stimmt. 


Computer kann ihn zu einer Zeit benutzen. Die Bus- 
steuerung muß abgefragt, zugeteilt und vom derzeitigen 
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Bild 1. In einem System mit gemeinsamen Bus im Time-Sha- 
ring-Betrieb (TSCB) kommunizieren mehrere Mikrocomputer 
mit gemeinsamen E/A-Einheiten und/oder Speicherbereichen 
miteinander über den Systembus 











zum neuen Master übergeben werden. Die verschiede- 
nen Systeme, die hier beschrieben werden, unterschei- 
den sich insbesondere in der Weise, wie die Computer 
miteinander kommunizieren und wie die Bussteuerung 
zwischen ihnen übergeben wird. In Systemen mit hoher 
Effizienz muß der Busarbitration sehr schnell, die Aus- 
wahl des Partners in einem Vorgang und der Datentrans- 
fer in möglichst kurzer Zeit durchgeführt werden. Ein 
wichtiger Gesichtspunkt bei der Aufteilung des Anwen- 
derprogramms ist die Minimierung der Zahl globaler 
Variablen, die zwischen den Computern transferiert 
werden müssen. Prioritätscodierung, Arbitration und 
Bus-Steuerfunktionen sind verteilt, wenn keine zentrale 
Steuereinheit vorgesehen ist. Alle Steuerfunktionen 
werden von den am Bus angeschlossenen Einheiten 
ausgeführt. 

Die Systemeffizienz hängt auch sehr stark von der Art 
des Speichers ab, der für die globalen Variablen benutzt 
wird. Der Globalspeicher kann zentral (für alle) oder 
verteilt bei den N Prozessoren angeordnet sein. Im letz- 
ten Fall beeinflußt die Aufteilung und die Art des 
Zugriffes durch andere Prozessoren die Gesamteffizienz. 
Eindeutige Adressierung ist eine Grundvoraussetzung, 
die durch Mapping des Speichers eines jeden Prozessors 
in den globalen Speicherbereich erreicht wird (siehe 
Teil 1, Bild 4). Auf diese Weise kann der Speicher eines 
jeden Partners durch Hinzufügen von wenigen Bits zur 
lokalen Adresse adressiert werden. Um lokale Daten 
und Programme zu schützen, ist es wünschenswert, den 
Speicherbereich, der globale Variable enthält, vom Rest 
zu trennen und ausschließlich darauf den Zugriff zu 
beschränken. Die erforderliche Zeit für den Zugriff auf 
den Speicher eines Partners wird sehr stark reduziert, 
wenn die globalen Variablen in einem Dual-Port-Spei- 
cher untergebracht sind. 


2 TSCB-System mit Einplatinen-Computern 


Für jeden Mikroprozessortyp gibt es verschiedene 
Einplatinen-Computer. Allerdings haben nur wenige 


SBC-86/12 


SBC-86/12 SBC-86/12 





Bild 2. Bis zu drei Einplatinen-Computer SBC-86/12 können 
zu einem Multiprozessor-System unter Verwendung der 
Daisy-Chain-Prioritätscodierung verknüpft werden 











dieser Boards Einrichtungen zum Multiprozessorbe- 
trieb. Wenn die Anwendung die Möglichkeiten eines 
einzelnen Computers überschreiten, können zwei oder 
mehrere miteinander verbunden werden und als ein 
Multiprozessorsystem arbeiten. Dies gilt insbesondere 
für die neuen 16-Bit-Mikroprozessoren (8086, Z8000, 
68000) weil diese CPUs besondere Hard- und Software- 
merkmale für Multiprozessorbetrieb besitzen. Beispiels- 
weise bietet der Typ Z8000 vier Signalleitungen 
(BUSRQ*, BUSAK*, MI*, MO*) sowie vier Instruktio- 
nen (MBIT, MERQ, MRES, MSET), um Bus-Anfragen, 
Prioritätscodierung sowie Busarbitrations-Operationen 
auszuführen. 


2.1 Multiprozessorbetrieb mit den Single-Board- 
Computern von Intel 


Die meisten Einplatinencomputer von Intel sind Mul- 
tibus-kompatibel. Nur wenige besitzen die Möglichkeit 
zum Multiprozessorbetrieb. Der Typ SBC 86/12, der eine 


‚Dreifach-Bus-Architektur besitzt, basiert auf der 16-Bit- 


CPU 8086, bietet 32 KByte „Pseudo-Dual-Port-Memory“, 
serielle sowie parallele E/A-Einheiten und das Multima- 
ster-Businterface. Der Dual-Port-Controller verbindet 
entweder den Systembus oder den lokalen Bus mit dem 
Speicher. Wenn dieser am Multibus angeschlossen ist, 
werden externe Adressen durch Hinzufügen von Displa- 
cements ergänzt. Deswegen kann nur eines von vier 
Segmenten vom Multibus adressiert werden [11]. 

Der SBC 86/12 verfügt über einfache Busarbitrationen, 
die serielle Prioritätscodierung (Daisy-Chain) auf der 
Platine benutzt (Bild 2). Die Anzahl der Prozessoren (N), 
die auf diese Weise kombiniert werden können, wird 
durch die Verzögerungszeit des höchsten Prioritätsaus- 
gangs (BPRO*) zum Eingang mit geringster Priorität 
(BPRN*) auf drei begrenzt. Diese Verzögerung kann 
100 ns oder eine Bus-Taktperiode von 10 MHz nicht 
überschreiten. Tatsächlich können bei geringerer Takt- 
frequenz des Busses mehr Prozessoren aneinander 
geschaltet werden, allerdings geht die Systemeffizienz 
sehr stark zurück [12]. 

Eine wesentlich bessere Möglichkeit, um die Anzahl 
der Prozessoren in einem System zu erhöhen, ist die 
Verwendung einer parallelen Bus-Arbitrationslogik 
(extern am SBC 86/12), wie sie für den S-100-Bus (siehe 
Teil 1, Bild 7) definiert ist oder vom Busarbiter-Baustein 
8289 von Intel (Bild 3) geboten wird. Hier werden bis zu 
16 Bus-Request-Leitungen mit einem zentralen 
Prioritätscodierungs-Netzwerk verbunden (bestehend 
aus 2 x 74148 und 2 X 74138). An dessen Ausgängen 
liegen die BPRN*-Signale an. Mit jeder dieser Methoden 
ist es dem derzeitigen Bus-Master immer möglich, seine 
Aktivitäten auf dem Bus zu beenden, bevor er die Steue- 
rung einem Master mit höherer Priorität übergibt. 
Außerdem kann der Bus-Master die Kontrolle über den 
Bus durch „Verriegelung“ behalten. Diese Möglichkeit 
wird benötigt, wenn kritische Funktionen beim Testen 
oder Setzen von Semaphoren oder Ausführen bestimm- 
ter E/A-Funktionen vorliegen. 
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2.2 Multiprozessorbetrieb mit dem SBC-8000 


Der Einplatinen-Computer SBC-8000, der vom Verfas- 
ser konstruiert wurde, bevor solche Platinen von Zilog, 
AMD oder anderen Firmen verfügbar waren, besitzt eine 
CPU Z8002, 16 KByte Programmspeicher und 4 KByte 
Datenspeicher, fünf 16-Bit-Zähler, eine serielle RS-232- 
Schnittstelle sowie 32 diskrete E/A-Anschlüsse. Die 
Architektur benutzt eine dreifache Busstruktur: den 
ungepufferten Z8000-Bus, den lokalen Z-Bus und den 
ZBI-Bus (Zilog Backplane Interconnect). 

Zwei Gruppen von Puffern verbinden wie ein mehr- 
poliger Umschalter den ungepufferten Z8000-Bus mit 
dem lokalen Bus, wenn ein Memory-Request-Signal 
(MEMRQ) vorliegt, oder mit dem Systembus, wenn ein 
E/A-Request-Signal (IORQ) vorliegt. Speicher und E/A- 
Funktionen sind lokal angeordnet, und die Memory- 
Mapped-Ressourcen befinden sich am lokalen Bus. 
Alles, was an den Systembus angeschlossen ist, sind 
E/A-Mapped-Global-Ressourcen, auf die nur mit einer 
E/A-Operation zugegriffen werden kann [13]. 

Um die Hardware des SBC-8000 zu beschränken, war 
ein wichtiger Gesichtspunkt bei der Entwicklung die 
Ausnutzung der oben erwähnten Merkmale in der Hard- 
und Software des Z8000, die den Multiprozessorbetrieb 
unterstützen: Daisy-Chain-Prioritätscodierung sowie 
firmwareimplementierte Arbitration (Bild 6). Um einen 
SBC-8000 mit dem Bus verbinden, muß das Programm 
eine MEMRQ-Instruktion ausführen, die die erste MI*- 
Leitung (Micro In) testet, darauf die MO*-Leitung (Micro 
Out) zuweist und nach einer vorher festgelegten Verzö- 
gerungszeit die MI*-Leitung erneut testet. Wenn beim 
zweiten Test das MI*-Signal auf High liegt, wird der 
Anfrager zum Bus-Master [14]. 

Wenn der Zugriff auf den Bus erfolgt ist, wählt der 
Master seinen Partner aus, indem er eine 3-Bit-Adresse 
auf den Systembus legt (Bild 4). Die Adreß-Decodie- 
rungslogik des ausgewählten Prozessors erzeugt ein Bus- 
Request-Signal, das dafür sorgt, daß die CPU die Kon- 
trolle über ihren lokalen Bus nach nicht mehr als 10 
Taktzyklen (2,5 us) wiedererlangt. Sobald der Partner 
dieses mit dem BUSAK-Signal (Bus Acknowledge) quit- 
tiert, kann der Master den Austausch von Daten mit den 
Ressourcen des Partners starten, wobei normale E/A- 
Operationen benutzt werden. 

Firmwareimplementierte Arbitration und Zugriff auf 
den Speicher des Partners mit Bus-Request ist langsam. 
Die Ausführung der MEMRQ-Instruktion kann eine Zeit 
von bis zu 10 us beanspruchen, weil eine interne Verzö- 
gerung von mindestens 3 us (2,5 us ist die maximale 
Reaktionszeit für BUSRQ) in der MEMRQ-Instruktion 
vorgesehen werden muß. Daraus ergibt sich eine erfolg- 
reiche Gesamtzeit, die für den Zugriff auf ein einzelnes 
Wort aus dem Speicher des Partners benötigt wird, von 
typisch 20 us, was viel zu lang ist für einen effizienten 
Datentransfer. 

Die Zugriffszeit zum Bus und zum Speicher des Part- 
ners kann um einen Faktor von 2 reduziert werden, 
wenn parallele Prioritätscodierer/Arbiter sowie ein ech- 
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tes Dual-Port-RAM benutzt werden. Diese Verbesserung 
rechtfertigt den relativ kleinen Aufwand an Hardware 
und für die zusätzlichen Bus-Prioritäts-Leitungen (drei 
für ein 8-Prozessorsystem). Allerdings sind echte Dual- 
Port-RAMs derzeit noch nicht verfügbar. Ein solches 
Bauelement, ein 4-Kx8-RAM, wird von Motorola im 
Laufe des Jahres 1982 eingeführt. Wenn nur ein paralle- 
ler Prioritätscodierer/Arbiter verwendet wird, kann die 
Zeit zum Datentransfer bereits wesentlich verringert 
werden (Bild 5). 


3 TSCB-Systeme mit Einchip-Controllern 


Einchip-Controller (SCC - Single Chip Controller) wie 
z.B. Z8, 6801, 6500/1, 8051 oder 9940 sind komplette 
Prozessoren mit CPU, Daten-/Programmspeicher, seriel- 
ler und paralleler E/A-Einheit und für Anwendungen 
mit großen Stückzahlen und geringem Verkaufspreis 
konzipiert (Werkzeuge, Spiele, Automobile usw.). Die 
Leistung ist begrenzt, aber trotzdem recht beeindruk- 
kend: Ein 8051 führt beispielsweise eine 8-Bit-Register- 
addition in einer us und einem 8-Bit-Multiplikation in 
vier us aus. SCCs bieten das geringste Kosten/Leistungs- 
verhältnis [15]. 

Es ist nicht überraschend, daß häufig versucht wird, 
eine Anzahl von SCCs in Multiprozessorsystemen zu 
verknüpfen, die nicht nur höhere Leistung als ein ein- 
zelner SCC bieten, sondern schrittweise erweiterungsfä- 
hige Merkmale (Durchsatz, Speicher- und E/A-Kapazi- 
tät) aufweisen, um Anforderungen unterschiedlichster 
Anwendungen in möglichst kosteneffektiver Weise ent- 
sprechen zu können. 

Unglücklicherweise sind die meisten SCCs nicht für 
Multiprozessor-Betrieb konzipiert. Nur die 8070-Typen 
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Bild 3. Bis zu 8 oder 16 Einplatinen-Compu- 

ter SBC-86/12 können zu einem Multiprozes- 
sor-System verknüpft werden, wenn zur parallelen Prioritätsco- 
dierung ein oder zwei Bausteine vom Typ 74148 und 74138 
benutzt werden 














sowie die 8051-Familie haben begrenzte Möglichkeiten 
für den Multiprozessor-Betrieb. Aus diesem Grunde exi- 
stieren nicht nur alle oben erwähnten Probleme, die für 
die Einplatinen-Computer gelten, sie werden sogar noch 
verstärkt. Die Kommunikation zwischen den Prozesso- 
ren ist beispielsweise besonders langsam bei Architektu- 
ren, die einen seriellen Bus benutzen. Trotzdem bieten 
serielle Bussysteme eine akzeptable Lösung bei Applika- 
tionen mit umfangreichen, unabhängigen Tasks und 
wenigen globalen Variablen, die ausgetauscht werden 
müssen. 

Die Typen Z8, 6801 sowie 8051 sind 8-Bit-Controller 
mit 128 Byte RAM und 2048 Byte ROM, einem oder 
zwei Zeitgebern, Taktgenerator, UART sowie bis zu 32 
programmierbaren E/A-Anschlüssen, die in vier 8-Bit- 


Ports aufgeteilt sind. Unterschiede bestehen in Taktfre- 
quenz, Ausführungszeiten, RAM-, Register- und Portor- 
ganisation, Befehlssatz sowie der Prototypen-Ausfüh- 
rung. Intel und Motorola bieten ein EPROM auf dem 
Chip an, während Zilog einen Baustein mit aufsteckba- 
rem EPROM entwickelt hat. 


3.1 Multiprozessorbetrieb mit den Einchip-Computer 
NS 807X 


Die 8070-Familie von National Semiconductor besteht 
aus verschiedenen Prozessoren, die alle eine 8-Bit-CPU, 
verschiedene 8/16-Bit-Register, 64 Byte RAM, Taktgene- 
rator auf dem Chip, Bus-Zugriffslogik sowie unter- 
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Bild 4. Der ungepufferte Z8000-Bus wird durch zwei Gruppen von Puffern, die wie ein mehrpoliger Umschalter wirken, entweder 
mit dem Z-Bus oder dem ZBl-Systembus (Zilog Backplane Interconnect) verbunden 
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schiedliche ROM-Kapazitäten bieten: der Typ 8070 hat 

kein, 8072 insgesamt 2,5 KByte, der 8074 eine Kapazität 

von 4 KByte ROM. Auf dem Chip befinden sich keine 

UART und kein Zähler. Diese Bausteine unterscheiden 

sich von anderen SCCs, die isoliert betrieben werden 

können, weil sie folgende Merkmale besitzen: 

© Ein permanentes Businterface (16 Adressen, 8 Daten- 
leitungen) anstelle der konventionellen programmier- 
baren E/A-Leitungen. 

@® Spezielle Wortverarbeitungs-Instruktionen wie z.B. 
„Suche und springe, falls das Zeichen übereinstimmt“ 
oder „Verzweigung falls kein Zeichen vorliegt“. 

© Besondere Signale, z. B. Bus-Request, Freigabe von 
Ein- und Ausgang, um den Multiprozessorbetrieb zu 
unterstützen. 

@ Relativ schnelle 16-Bit-Multiplikation (37 us) sowie 
-Division (42 us). 

Multiprozessorbetrieb mit den SCCs aus der 8070- 
Familie wird durch die Bus-Zugriffs-Logik, dem ILD- 
(Inkrement und Laden) sowie DLD-Befehl (Dekrement 
und Laden) außerordentlich stark vereinfacht. Unter 
Verwendung von Daisy-Chain-Codierung können ver- 
schiedene 8070-Bausteine über einen Parallelbus und 
die Bus-Request-Leitung verbunden werden. Es sind 
keine zusätzlichen Bauelemente notwendig [16]. 

Die einzelnen Bausteine vom Typ 8070 in einem Mul- 
tiprozessorsystem (Bild 6) werden durch Anschluß des 
ENOUT*-Ausganges einer Einheit mit höherer Priorität 
an den ENIN*-Eingang des nächsten Bausteines in der 
Linie priorisiert. Wenn ein Prozessor den Bus benötigt, 
muß er das BERQ*-Signal überprüfen, bevor einer der 
Speicher-Referenz-Funktionen ausgeführt wird. Wenn 
BREQ* nicht aktiv ist, zieht der Prozessor 8070 diese 
Leitung auf Low-Potential und überprüft sein ENIN*- 
Signal. Im einzelnen kann folgendes eintreten: 
® Wenn ENIN* auf High-Potential liegt, wird ENOUT* 

auf High gesetzt und dem 8070 der Zugriff auf den Bus 

gesperrt. 

@© Wenn ENIN* auf Low-Potential liegt, wird ENOUT* 
auf High gesetzt und dem 8070 wird der Zugriff aufden 
Bus gestattet. 

Diese Prozedur arbeitet in Zusammenhang mit spe- 
ziellen Softwareoperationen auch, wenn verschiedene 
Prozessoren gleichzeitig auf den Bus zuzugreifen versu- 
chen. Wenn der Prozessor mit der höchsten Priorität 
seine Operationen beendet hat, bzw. einen integralen 
Teil davon (z. B. ein Byte in einer ILD-Instruktion auf- 
nehmen), gibt er den Bus wieder frei, indem er die 
BREQ*-Leitung auf High-Potential schaltet, so daß der 
nächste Prozessor, der an der Reihe ist, auf den Bus 
zugreifen kann. Aus diesem Grund wird jeder wartende 
Prozessor berücksichtigt, bevor neue Bus-Requests 
erlaubt sind. Dieses Verfahren vermeidet das Problem 
des Ausschlusses und minimiert die Zeit, die ein Pro- 
zessor auf dem Buszugriff warten muß. 

Ein gemeinsamer Speicher ermöglicht den Austausch 
globaler Variabler zwischen den Prozessoren. Auf den 
Speicher kann von allen Prozessoren aus über normale 
Schreib-Lese-Operationen zugegriffen werden. Die 16 
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Adreßleitungen erlauben direkte und schnelle Adressie- 
rung des internen ROMs (0000...09FF) sowie RAMs 
(FFCO...FFFF) und eines externen RAMs (OFFF...FFBF). 
Die ILD- und DLD-Instruktionen ermöglichen Read- 
Modify-Write-Operationen durch spezielle Flags (Spei- 
cherplätze), um Semaphoren-Behandlung zu unter- 
stützen. 

Derzeit ist die einzige Literatur, in der die Multipro- 
zessor-Operationen dieser Familie beschrieben werden, 
das Datenblatt des INS8070 [17], allerdings ist ein aus- 
führlicheres Applikations-Handbuch in Vorbereitung. 


3.2 Multiprozessor-Betrieb mit dem Einchip-Computer 
8051 


Ein bisher einmaliges Merkmal für einen Baustein 
dieser Art ist das Kommunikationsprotokoll der UART 
im 8051 von Intel [18]. Damit ist es möglich, eine große 
Anzahl Prozessoren über einen seriellen Bus zu verbin- 
den. Das dadurch entstehende System ist, obwohl für 
räumlich getrennte Prozessorsysteme konzipiert, beson- 
ders interessant, weil es echte blockweise Erweiterungs- 
fähigkeit besitzt, ohne daß zusätzliche Bauelemente 
erforderlich sind. 

Die Hardware der UART des 8051 ist konventionell 
aufgebaut. Die Multiprozessorfähigkeit wird durch meh- 
rere Ebenen im Protokoll gegeben. Das Register für die 
Steuerung des seriellen Ports (SCON) erlaubt z. B.: 1. 
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Bild 5. Ein S-100-Parallel-Prioritätscodierer und -Arbiter paßt in 
einfacher Weise die MI*- und MO*-Leitungen des Z8000 an und 
erfordert nur drei zusätzliche Prioritätsleitungen auf dem Sy- 
stembus 











Auswahl der vier Betriebsarten mit den SMO- und SM1- 
Flags, 2. Konditionierung und Freigabe des Empfängers 
mit den REN- und SM2-Flags, 3. Setzen des Empfänger-/ 
Sender-Bit 8 mit RB8 und TB8 sowie 4. Steuerung der 
Flags RI und TI für Sende-/Empfangs-Ende. Die Betriebs- 
art 3 (11-Bit-Übertragung mit konstanten 187,5 kBaud) 
wurde insbesondere für die Kommunikation zwischen 
den Prozessoren konzipiert. Wenn das neunte Rahmen- 
Bit gesetzt ist, aktiviert ein Reception-Complete-Inter- 
rupt (RI) den Prozessor. 

Die Kommunikation des 8051 mit anderen Prozesso- 
ren [19] basiert auf einem Master-Slave-Protokoll, in 
dem 'ein Master und mehrere Slaves vorgesehen sind. 
Das Protokoll umfaßt folgende Schritte: 

@ Der Master überträgt eine 8-Bit-Adresse des Slave, die 
durch ein aktives Bit TB8 im SCON bezeichnet ist. 
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mit niedrigerer Prioritat ) 


Bild 6. Mehrere Einchip-Controller 807X werden über einen 
24poligen Adreß-/Datenbus sowie eine einzelne Bus-Request- 
Leitung miteinander verknüpft. Die Freigabeanschlüsse wer- 
den hintereinandergeschaltet (Daisy-Chain), so daß der ober- 
ste Prozessor die höchste und der unterste die niedrigste 
Priorität hat 











® jede UART der Slaves wartet auf die Adresse. Wenn 
diese vorliegt und wenn das Bit SM2 gesetzt ist, unter- 
bricht sie die CPU, die die Adresse mit der eigenen 
vergleicht. 

© Der angewählte Slave setzt in seinem SCON das Bit 

SM2 zurück, um alle folgenden Aussendungen des 

Masters zu empfangen. 
® Der Master sendet die Steuerinformationen wie 

„Schreiben“ oder „Lesen“ sowie die Daten. 

Die Netzwerkeffizienz kann darüber hinaus noch ver- 
bessert werden, wenn Software definiert wird, die Steu- 
erbits in der Adresse erkennt. Wenn z.B. Bit7 des 
Adreßrahmens für den Master gesetzt ist, sind alle Sla- 
ves zum Empfang der folgenden Nachricht freigegeben, 
wenn Bit 7 logisch Null ist, kann nur der angewählte 
Slave die Nachricht empfangen. In ähnlicher Weise zeigt 
das Bit B7 im Slave-Rahmen das Erkennen eines Kom- 
mandos mit einer 1 oder einen Fehler mit einer 0. 

Typisch für Multi-Mikroprozessorsysteme mit dem 
8051 ist das Master-Slave-Prinzip. Dabei ist die gesamte 
Steuerung verteilt und befindet sich in den UARTSs der 
Prozessoren und deren Software. Die Master-Slave- 
Architektur schließt Zugriffskonflikte auf dem Bus aus, 
weil der jeweilige Master die Steuereinheit darstellt und 
bestimmt, was jeder Slave tun muß und in welcher 
Reihenfolge dies zu geschehen hat. . 

Mit einer Rate von 187,5 kBaud und in einem Rahmen 
von 11 Bit können Datenbytes zwischen Master und 
Slave innerhalb von 58 us übertragen werden. Um Daten 
zwischen zwei Slaves transferieren zu können, muß der 
Master erst ein Kommando zum aussendenden Slave 
senden, bevor die eigentliche Übertragung beginnen 
kann. Das hat zur Folge, daß ein Multi-Mikroprozessor- 
system mit Einchip-Computern vom Typ 8051 nur lang- 
samen Datentransfer über den seriellen Bus unterstützen 
kann. 

Die UART des 8051 unterstützt sowohl Duplex- als 
auch Halb-Duplex-Datenübertragung (Bild 7). Theore- 
tisch können in einem solchen System bis zu 128 Pro- 
zessoren kombiniert werden. Praktisch ist die Zahl 
durch die Treiberkapazität der Transmitter sowie die 
Kapazitäts- und Rauscheigenschaften des Verbindungs- 
kabels begrenzt. Die tatsächlich realisierbare Anzahl der 
kombinierbaren Einzelprozessoren hängt daher von der 
Kabellänge, der Abschirmung und dem elektromagneti- 
schen Störpegel der Umgebung ab. 


4 Multi-Mikroprozessor-Software 


Software für Systeme mit einem einzigen Prozessor 
besteht aus dem Anwendungsprogramm, dem Betriebs- 
system, das die Steuerung oder die Programme zur Ver- 
waltung der Ressourcen (Supervisor, Executive usw.) 
sowie die Software-Entwicklungsunterstützung (Über- 
setzer, Dienst- und Diagnose-Programme) umfaßt 
(Bild 8a). 

Multiprozessor-Software (Bild 8b) unterscheidet sich 
davon insbesondere im Betriebssystem. Multiprozessor- 
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Betriebssysteme (MPOS) müssen lokale und globale 

Ressourcen verwalten sowie die Kommunikation zwi- 

schen den Prozessoren steuern können. Das Maß der 

Verantwortung in der Verwaltung hängt sehr stark von 

der Architektur des Multi-Mikroprozessor-Systems, dem 

Grad der Kopplung zwischen den Prozessoren sowie 

davon ab, ob die Steuerung zentral oder verteilt angeord- 

net ist [20]. 

Die Steuerfunktionen eines Multiprozessor-Betriebs- 
systems müssen dafür sorgen, daß die Tasks, die in den 
verschiedenen Prozessoren zu verschiedenen Zeiten 
ausgeführt werden, nicht miteinander in Konflikt gera- 
ten und das System zum Zusammenbruch oder Blockie- 
ren bringen. Im einzelnen muß ein solches Betriebssy- 
stem folgende Funktionen ausführen: 

@ Synchronisierung der Prozessoren und Prozesse durch 
zeitlichePlanungder Tasks (Scheduling), Priorisierung 
und ihre Ausführung; 

® Verwaltungund Aufteilung der lokalen sowie globalen 
Ressourcen (Speicher, CPUs, Busse, E/A-Einheiten 
usw.), abhängig vom Grad der Verkopplung der Prozes- 
soren; 

@ Bereitstellung von Einrichtungen für Diagnose, Rekon- 
figuration und Wiederaufnahme des Betriebes, um 
bestimmen zu können, welches Element fehlerhaft 
arbeitet, dieses abzuschalten und das System neu zu 
starten. 


4.1 Weiterentwicklung von Multi-Tasking-Betriebssyste- 
men (MTOS) zu Multiprozessor-Betriebssystemen 
[MPOS) 





Echtzeit-Multi-Tasking-Betriebssysteme gibt es mitt- 
lerweile für die meisten 8- und 16-Bit-Mikroprozessorfa- 
milien (iRMX 80/86, Versados, ZRTS/Zeus usw.), die die 
üblichen Funktionen des Ressourcen-Scheduling, der 
Steuerung und Verwaltung übernehmen. Der einfachste 
Weg, ein MPOS zu produzieren, ist die Multiprozessor- 
Steuerfunktionen einem existierenden MTOS hinzuzu- 
fügen. Die Firma Industrial Program Inc. (IPI) macht 
genau dieses und vermarktet eine ganze Familie von 
Multiprozessor-Betriebssystemen [21]. 

MTOS-68k, das Echtzeit-Betriebssystem für die Pro- 
zessorfamilie 68000 von Motorola, ist das neueste dieser 
Produkte. Es bietet nicht nur die Intelligenz, die es 
ermöglicht, daß mehrere Prozessoren als ein System 
funktionieren, es führt dieses auf eine Weise aus, daß 
das Anwendungsprogramm nicht berücksichtigen muß, 
wieviele Prozessoren im System vorhanden sind. 
MTOS-68k ist für Systeme mit 1...16 Prozessoren konzi- 
piert, die alle gleichwertige Partner sind. Es gibt keine 
Master oder Slaves. Das MTOS wird in jedem Prozessor 
gespeichert. 

Das Betriebssystem behandelt jeden Prozessor als eine 
Ressource, der Tasks zugeordnet werden können. Die 
Task mit der höchsten Priorität wird immer dem ersten 
verfügbaren Prozessor zugewiesen. Eine typische 
Betriebssituation könnte folgendermaßen ausschauen: 
Task X läuft auf Prozessor P und wird unterbrochen, um 
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eine höherpriorisierte Task Y auszuführen. Wenn Y 
abgeschlossen ist, wird die Ausführung von X weiterbe- 
arbeitet, aber möglicherweise auf einem anderen Prozes- 
sor. Im allgemeinen ist es nicht möglich, vorauszusagen, 
welcher Prozessor gerade welche Task ausführt, wenn 
nicht besondere E/A-Einheiten oder andere Hardware 
erforderlich sind. 

Die Möglichkeit, Tasks an verschiedene Prozessoren 
zur Ausführung zu verteilen, führt zu einer sehr wün- 
schenswerten Eigenschaft, nämlich der Softwaretrans- 
parenz. Das bedeutet, daß das Anwendungsprogramm 
unabhängig von der Anzahl der Prozessoren im System 
wird. Das hat auch zur Folge, dal das vollständige 
Programm zunächst auf einem einzelnen Prozessor aus- 
geführt werden kann. Wenn die Ausführungszeit zu lang 
ist, kann ein zweiter Prozessor — gegebenfalls auch mehr 
— hinzugefügt werden. Ein ähnlicher Fall tritt ein, wenn 
das Programm auf N Prozessoren ausgeführt wird und 
einer davon ausfällt. Dann kann ohne Unterbrechung 
des Programms die Ausführung weiterlaufen. 

Dieser Punkt ist besonders wichtig, denn Software- 
transparenz ist eine Voraussetzung für wirtschaftlich 
vertretbare Multi-Mikroprozessor-Software. 


Einige Spezifikationen des MTOS-68k: 


Speicherbedarf in Byte 


MTOS/MPOS-Kern 12000 
Dateiverwaltung 6150* 
Treiber: Konsole 900 
Floppy Disk 750* 
Zeilendrucker 850* 
Overhead/Task 70 
Overhead/Device 64 


*nicht erforderlich für Echtzeitsteuer-Systeme 























ud 


TXD RXD 


SCC 
8051 





1 
TXD RXD 


ScC 
8051 





Bild 7. Das Multiprozessor-System mit den Einchip-Computern 
8051 kann entweder mit einem Voll-Duplex- (a) oder Halb- 
Duplex-Bussystem (b) implementiert werden, beide arbeiten 
mit einer Übertragungsrate von 187,5 kBaud 
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Weitere Daten 


Prioritäts-Ebenen 256 
Event-Flags bis zu 512 
Ext. Descretes bis zu 8000 
Device-Typen bis zu 256 
Unit/Device bis zu 256 
Anzahl der Tasks bis zu 2048 
Mailboxes bis zu 256 
Anzahl der uPs bis zu 16 


MTOS-68k ist in 68000-Assemblersprache geschrie- 
ben und auf einer 8-Zoll-Diskette gespeichert. Das Basis- 
paket umfaßt den Kern, die MNPS-Option, den Konso- 
len-Treiber, Debugger, die Diagnoseeinrichtung und ein 
Demonstrationsprogramm. 
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Bild 8. Der grundlegende Unterschied zwischen Software für 
Einzelprozessoren (a) und Software für Multiprozessoren (b) 
liegt im Betriebssystem. Dieses muß die lokalen und globalen 
Ressourcen verwalten sowie die Kommunikation zwischen den 
Prozessoren steuern 











5 Zukünftige Entwicklungen 


Jedes Multiprozessorsystem besteht aus Hard- und 
Software, die zur Systemarchitektur mit dem System- 
bus, dem Kommunikationsprotokoll sowie einigen 
Interfaceschaltungen verknüpft sind. Einplatinen- und 
Einchip-Prozessoren stellen die Hardware, Anwen- 
dungsprogramme und Betriebssysteme formen die Soft- 
ware. Derzeit sind noch keine allgemein verwendbaren 
Multi-Mikroprozessor-Systeme verfügbar, nur einige 
Hard- und Softwarekomponenten. 

Unglücklicherweise sind diese Komponenten von ver- 
schiedenen Firmen entwickelt worden. Deshalb ist es 
nicht ganz einfach, diese zu kombinieren und zu erwar- 
ten, daß sie sofort ein arbeitsfähiges System ergeben, 
auch wenn sie zur gleichen Mikrocomputerfamilie gehö- 
ren. Aufwendige Anpassungen und Modifikationen sind 
erforderlich, um ein betriebsfähiges System zu bekom- 
men. Der größte Teil der Entwicklungsarbeit ist daher 
für die Optimierung und Erhöhung der Effizienz eines 
Multi-Mikroprozessor-Systems erforderlich. 

Es bleibt zu hoffen, daß dieser Zustand sich in der 
nächsten Zukunft ändern wird, wenn Mikrocomputer- 
hersteller ihre eigenen MPOS entwickelt haben werden 
oder einige Softwarehäuser für jeden Mikroprozessor 
ein solches Betriebssystem anbieten. Der 32-Bit-Prozes- 
sor IAPX 432 von Intel zeigt die Richtung auf, in die die 
zukünftige Entwicklung gehen wird. Dieser Typ und 
seine Architektur in Multiprozessor-Anwendungen wer- 
den an anderer Stelle in diesem Heft beschrieben. 

Im nächsten Artikel dieser Reihe werden die Lei- 
stungsmerkmale des TSCB-Multiprozessorsystems vor- 
gestellt und analysiert, wobei die Zufalls- und Reihen- 
theorie benutzt wird. Eine Computersimulation eines 
typischen Systems wird ebenfalls dargestellt. 
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Multi-Mikroprozessor-Systeme 


3. Teil: Leistungsmerkmale 


In diesem Beitrag sollen die verschiedenen Theorien 
für die Bestimmung der Wartezeit und der Effizienz 
eines TSCB-Multi-Mikroprozessor-Systems (Time-sha- 
red common-Bus) vorgestellt werden, wobei entweder 
eine Vorrichtung für Vermeidung von Zugriffskonflik- 
ten oder eines der verschiedenen Warteschlangen- 
Konzepte Verwendung findet. Außerdem wird ein 


1. MMPS-Leistung — 
Herausforderung an den Entwickler 


Einer der Vorteile, die in Zusammenhang mit Multi- 
Mikroprozessor-Systemen immer wieder erwähnt wer- 
den, ist das bessere Preis/Leistungs-Verhältnis, das sich 
im Gegensatz zu Systemen mit nur einem Prozessor 
erreichen läßt. Dieser Punkt wird aber nur dann nach- 
weislich erfüllt, wenn die Leistungsmerkmale eines 
MMPS genau definiert, vorausbestimmt und gemessen 
werden können. Dieses Problem ist allerdings bis heute 
noch nicht ausreichend gelöst, weil derzeit die lei- 
stungsbestimmenden Faktoren eines Systems mit nur 
einem Prozessor noch nicht einheitlich definiert sind. 
Das ist allerdings eine Voraussetzung für die eindeutige 
Bestimmung der MMPS-Leistung. (Siehe auch Kasten 
„Definitionsmöglichkeiten für die Leistung von Syste- 
men mit einem Prozessor“.) 

Die Definition der Leistung eines MMPS ist sogar 
dann problematisch, wenn man voraussetzt, daß die 
Leistung des einzelnen Prozessors bekannt ist. Das liegt 
an der starken Abhängigkeit dieses Merkmals von Archi- 
tektur und Anwendung. Die vielen Parameter, die im 
einzelnen die Leistung beeinflussen, können in folgende 
Gruppen eingeteilt werden: 
® Die Anzahl und Typen des Datentransfers zwischen 

den Prozessoren, die wiederum abhängig sind von 

— der Größe des Programms und den Möglichkeiten, 

wie dieses aufgeteilt werden kann, 

— der Anzahl der globalen Variablen und deren gegen- 

seitigen Abhängigkeit. 
@ Die Anzahl und die Typen der Prozessoren im System 
sowie deren Funktionen 
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Modell zur Computersimulation des TSCB-Systems 
beschrieben und dessen Ergebnisse mit den theoreti- 
schen Resultaten verglichen. Dadurch soll ein tiefer 
Einblick in alle Faktoren, die die Leistung eines MMPS 
beeinflussen, gegeben werden, so daß architektoni- 
sche Gesichtspunkte schon in einem frühen Stadium 
berücksichtigt werden können. 


— Mastern, Slaves, Coprozessoren, intelligente Peri- 
pherie-Einheiten, 
— auf eine bestimmte Aufgabe zugeschnitten oder mit 
dynamischer Task-Zuweisung. 
® Typ, Bereich und Zugriffsart des Speichers für die 
globalen Variablen 
— lokaler und globaler Speicher oder beides, 
— Speicher mit einseitigem oder zweiseitigem Zugriff 
(Dual-Port-Memory), 
— Speicherzugriff: über CPU, DMA oder direkt, z. B. 
Dual-Port-Memory. 
®@ Die Anzahl, der Typ und die Konfiguration der System- 
busse 
— parallel, seriell, Adreß-, Daten-, Steuer-Multiplex 
usw., 
— Datenübertragungsrate (Taktfrequenz), Transfer-Ka- 
pazität, 
— Typ und Geschwindigkeit des Prioritätscodierers. 
@ Die Effizienz der Kommunikation zwischen den Pro- 
zessoren, bzw. die Verzögerung bei 
— Zugriff auf den Bus, Vergabe und Zuteilung der 
Steuerung, 
— Auswahl eines Partners durch Aussenden einer 
Adresse, 
— der Abgabe der Steuerung des Busses durch den 
Partner, 
- der Adressierung des Speichers des Partners und 
dem Transfer der Daten. 
Hier sind nur die wichtigsten Parameter aufgeführt. Es 
ist deshalb nicht überraschend, daß eine praktisch 
anwendbare, aber trotzdem umfassende Methode zur 
Leistungsbestimmung von MMPS notwendig ist 
[24...42]. 


Weil der Grad der Schwierigkeit einer Analyse mit der 
Komplexität des Systems steigt, soll hier nur auf relativ 
einfache Systeme eingegangen werden, beispielsweise 
die Time-Shared-Common-Bus-Architektur, bei der N 
Prozessoren über einen einzigen Bus miteinander ver- 
bunden sind. 


2 Leistungsanalyse 
mit der Zugriffs-Konflikt-Methode 


Dieses relativ einfache Verfahren [36] wurde dazu 
benutzt, die Verzögerung beim Bus-Zugriff (Wartezeit) 
und die Prozessor-Effizienz eines Systems zu messen, in 
dem bis zu zehn 8080-CPUs miteinander verbunden 
sind, und zwar über einen einzelnen Bus und mit einem 
gemeinsamen Speicher. Folgende Voraussetzungen 
wurden gemacht: 
® Die CPU 0 hat die höchste, die CPU 9 die niedrigste 

Priorität. Busanforderungen niedrigerer Priorität wer- 

den zurückgehalten, bis der Bus frei ist, deshalb ist die 

CPU 0 eine Effizienz von 100 % und die der anderen 

entsprechend ihrer Priorität gringer. 
®Ein Instruktionszyklus besteht aus verschiedenen 

Subzyklen, von denen jede wiederum aus vier Maschi- 

nenzyklen besteht (t„), der Bus wird nur während eines 

der vier t„-Zyklen benutzt. 


® Die Wahrscheinlichkeit p;, daß die CPU i auf den Bus 
in einem gegebenen Zyklus zugreift, ist wegen dem 

Instruktionsformat des 8080 eine Konstante. 
® Die CPU-Effizienz kann als E;, = 1 — d; ausgedrückt 

werden, wobei d; die relative Verzögerungszeit ist, die 

am Prozessor p; gemessen wurde. 
© Die Konflikt-Wahrscheinlichkeit p.'" isteine Funktion 

von p; und der Anzahl N der Prozessoren am Bus. 
In diesem Fall wurden folgende Schlüsse gezogen: 
Erstens ist das beschriebene System — verschiedene 
CPUs greifen auf einen gemeinsamen Speicher zu — 
ineffizient und wird daher heute auch nicht mehr ange- 
wendet. Zweitens wird vorausgesetzt, daß die Zugriffs- 
wahrscheinlichkeit für alle CPUs gleich und konstant 
ist, was allerdings nicht sehr realistisch ist. Drittens sind 
die mathematischen Beziehungen, mit denen die 
Zugriffsverzögerungen bestimmt wurden, nicht angege- 
ben, sondern nur die Ergebnisse. 

Trotzdem kann das Verfahren als interessante Anre- 
gung dienen und für ein TSCB-System ausgeweitet wer- 
den. Dann kann es mit dem Verfahren, bei dem die 
Warteschlangen-Theorie verwendet wird, verglichen 
werden. In einem TSCB-System ist die Wahrscheinlich- 
keit von Buskonflikten sowie die Wartezeiten viel klei- 
ner, weil wesentlich weniger Verkehr auf dem Bus 





Definitionsmöglichkeiten 


Obwohl bereits beachtlicher Aufwand in die 
Lösung dieses Problems investiert wurde, gibt es 
noch keine einheitliche Methode für die genaue Defi- 
nition der Leistung von Systemen mit einem Prozes- 
sor durch möglichst wenige Parameter. Deshalb ist 
auch der Leistungsvergleich verschiedener Prozes- 
soren nicht möglich oder führt zu Fehlinterpretatio- 
nen, weil der wichtigste Parameter — der Durchsatz — 
von der speziellen Mischung der Instruktionen oder 
dem Anwendungsprogramm abhängt [30]. 

Durchsatz ist ein Maß dafür, wieviele Operationen 
pro s ausgeführt werden, oft in KOPS oder MOPS 
(tausend bzw. Millionen Operationen pro Sekunde) 
angegeben. Weil allerdings eine Registeraddition 
beispielsweise wesentlich weniger Zeit als eine 16- 
Bit-Multiplikation erfordert, beides aber einzelne 
Operationen sind, kann kein Vergleich des Durchsat- 
zes auf dieser Basis durchgeführt werden, wenn 
nicht das Programm oder die einzelnen Instruktionen 
genau spezifiziert sind. 

Ein Benchmark-Test ist ein Standard-Programm, 
mit dem die Leistung eines digitalen Prozessors 
gemessen werden kann. Wenn alle Anwender und 
Hersteller sich auf einheitliche Benchmark-Pro- 
gramme einigen würden, wäre das Verfahren 
wesentlich unproblematischer. Weil aber die Anfor- 
‘derungen der Benutzer höchst unterschiedlich sind 





für die Leistung von Systemen mit einem Prozessor 


(Echtzeit, keine Echtzeit usw.) und weil es im Inter- 
esse der Hersteller liegt, die Vorteile ihrer Produkte 
herauszustellen, wurden so viele unterschiedliche 
Benchmark-Typen entwickelt. In der letzten Zeit wur- 
den von drei unabhängigen Gruppen verschiedene 
Benchmarks auf den wichtigsten Prozessortypen 
(8086, Z8000, 68000 usw.) ausgeführt und miteinan- 
der verglichen [31...33]. Die dabei benutzten Pro- 
gramme wurden aus den bekannten Carnegie-Mel- 
lon-Benchmarks ausgewählt, die die unterschied- 
lichsten Applikationen einschließen. Die zur Ausfüh- 
rung erforderliche Zeit gibt wahrscheinlich das beste 
Maß für einen Vergleich des Durchsatzes. Allerdings 
kann man diesen Ergebnissen nur Bedeutung 
zumessen, wenn der Prozessor für die gleiche 
Anwendung eingesetzt wird wie im Benchmark. 


Viele andere wichtige Parameter werden 
benutzt, um einzelne Leistungsmerkmale des Pro- 
zessors zu charakterisieren: maximaler Speicher- 
Adreßbereich, Anzahl und Typ der E/A-Kanäle, Ver- 
lustleistung, Betriebsmöglichkeit in gestörter Umge- 
bung, Zuverlässigkeit, Abmessungen, Kosten usw. 
Obwohl diese Parameter für bestimmte Einsatzfälle 
zugeschnitten sind, sind sie natürlich nicht so sehr 
applikationsabhängig und können daher im einzel- 
nen sehr leicht verglichen werden. 
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herrscht. Für die Bestimmung der Parameter kann man 
dieselben mathematischen Beziehungen verwenden. 


3 Leistungsanalyse 
mit der Warteschlangen-Theorie 


In einem echten TSCB-System (Bild 1) kommunizie- 
ren die N Prozessoren, bestehend jeweils aus CPU, loka- 
lem Speicher und lokaler E/A-Einheit, über den gemein- 
samen Bus. Der Systembus wird im Multiplex-Betrieb 
benutzt, deshalb kann nur immer einer der N Prozesso- 
ren den Bus in Anspruch nehmen. Wenn mehrere Pro- 
zessoren gleichzeitig den Zugriff auf den Bus benötigen, 
kommt es zum Konflikt, der in Übereinstimmung mit 
den aufgestellten Prioritätsregeln gelöst werden muß 
(siehe auch Teil 1). Dadurch ergibt sich, daß die Prozes- 
soren geringerer Priorität auf die anderen warten müs- 
sen. Der Systembus kann deshalb als eine Warte- 
schlange angesehen werden, in die sich die Prozessoren 
für den Buszugriff einreihen müssen. Die Zeit, die in der 
Warteschlange verbracht werden muß, sowie die Dauer, 
die die Prozessoren an den Bus angeschlossen sind, 
stellen wichtige Parameter dar, die die Systemeffizienz 
beeinflussen. Weil jeder Prozessor seinen eigenen loka- 
len Speicher besitzt und weil nur globale Variable trans- 
feriert werden müssen, sind die Datentransfers seltener 
und die Wartezeiten kürzer als in Systemen, die nur 
über einen gemeinsamen Speicher verfügen. Die Zeit- 
dauer, während der Prozessor am Bus angeschlossen ist, 
(die Service-Zeit) hängt von der Datenübertragungs- 
Kapazität des Busses und dem Überbau an Zugriffs- und 
Kommunikations-Protokollen, die mit jedem Worttrans- 
fer verbunden sind, ab. 

Die Verwendung der Warteschlangen-Theorie zur 
Bestimmung der Leistung eines TSCB-Systems bietet 
sich an, weil sie bewährte Analyse-Werkzeuge bietet 
(siehe Kasten „Grundlegende Eigenschaften einer War- 


Grundlegende Eigenschaf- 
ten einer Warteschlange 


Die grundlegenden Charakteristiken einer Warte- 
schlange werden durch vier Parameter, die in der 
Gruppe A/B/C/D zusammengefaßt sind, angegeben. 
Dabei ist „A“ die Verteilung der Anfragen (Beschrei- 
bung des Zufallsprozesses), „B“ die Beschreibung 
des Zufallsprozesses (der Verteilung) der Abferti- 
gung, „C“ die Anzahl der Bediener und „D“ die 
Anzahl der Prozessoren. Im einzelnen werden die 
Merkmale von Warteschlangen folgendermaßen 
dargestellt: 

Mittlere Anfragehäufigkeit = A 

Mittlere Service-Zeit = T, 

Maximale Anzahl der Services von einer mittleren 
Service-Zeit T,in1s= u 


Warteschlange und 
Bediener 


Bus-Anfragen Bedienzeit (konstanter Bus-Abfertigung 
als Zufallsfolge oder Zufallswert) (bediente Prozessoren) 


0.000 00 0 000000 


Zugriffs-und Transferzeit 


teschlange“). Von den verschiedenen alternativen 
Methoden spiegelt keine ein MMPS ideal wieder. Um 
mit den Merkmalen und Grenzen der einzelnen Metho- 
den einschätzen zu können, ist es wichtig, mit der 
statistischen Wahrscheinlichkeit und den exponentiel- 
len Verteilungen vertraut zu sein [37, 38, 39]. 

Es werden drei alternative Methoden für Warteschlei- 
fen beschrieben, die sich in der Anzahl der Benutzer 
(endlich oder unendlich) und der Art der Service-Rate 
(exponentielle oder konstante Verteilung) unterschei- 
den. Die folgenden Voraussetzungen müssen gemacht 
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werden, bevor man sich für die eine oder andere 

Methode entscheidet: 

© Von den Kam Busangeschlossenen Prozessoren sindN 
im aktiven Zustand (es besteht die Möglichkeit der 
Busanforderung) und J im blockierten Zustand (ent- 
weder in der Warteschlange oder mit dem Bus ver- 
bunden). 

@ Busanforderungen der aktiven Prozessoren treten in 
zufälliger Reihenfolge auf, wobei die Wahrscheinlich- 
keit der Dauer zwischen zwei benachbarten Busanfor- 
derungen exponentiell mit dem Mittelwert 1/X verteilt 
ist. Alle Prozessoren haben gleiche Anforderungsraten, 
\ ist die Häufigkeit. 

® Die Länge des Datentransfers ist eine Zufallsfunktion 
und mit dem Parameter 1/u exponentiell verteilt. Das 
ist nicht typisch für ein TSCB-System, aber es verein- 
facht die Analyse. Die dadurch verursachten Effekte 
werden später diskutiert. 


3.1 Die M/M/1/®-Warteschlange 


Diese Warteschlange besitzt eine Anfrage-Häufigkeits- 
rate nach Markovian (Poission), eine Abfertigungsrate 
nach Markovian (exponentiell), einen einzigen Bediener 
und eine unendliche Anzahl von Benutzern. Diese Form 
der Warteschlange kann mit einem einfachen Satz von 
Bestimmungsgleichungen charakterisiert werden. Die 
drei Schlüsselparameter (Verkehrsintensität o, Anzahl 
der Prozessoren im System L, und die Wartezeit W) 
können sehr einfach mit den zwei Eingangsvariablen A 
und u berechnet werden. 

Exponentielle Service-Rate: 
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Bild 2. Der Mittelwert der Zeitdauer, die ein Prozessor in einem 
TSCB-System warten muß, steigt exponentiell mit der Intensivität 
des Busverkehrs oder der Anzahl der ausgeführten Datentransfers. 
Der Sättigungseffekt der M/M/1/N-Warteschlange wird durch die 
Tatsache verursacht, daß mit der wachsenden Zahl der Prozessoren 
im System (in der Warteschlange oder am Bus) die abnehmende 
Anzahl der aktiven Prozessoren weniger Busanforderungen verur- 
sachen. Das System regelt sich selbst 





(Bus-)Verkehrsintensivität: 
oe = Mu 


Mittlere Anzahl der blockierten (wartenden oder gerade 
bediente) Prozessoren im System: 


L = o/(1-o) 
Mittlere Wartezeit im System: 


W=LA 


3.2 Die M/D/1/»-Warteschlange 


Diese Warteschlange besitzt eine Anfrage-Häufigkeit 
nach Poisson, eine konstante Service-Zeit und eine 
unendliche Zahl von Benutzern. Die mathematischen 
Beziehungen sind ein wenig komplizierter, aber sie 
benutzen konstante Service-Zeit. Das Gleichungssystem 
wird mit Hilfe der Pollaczek-Khintchine-Formel [40] 
aufgestellt: 

Mittlere Anzahl der blockierten Prozessoren im System: 


= 0 + 0*/2(1-g) 
Mittlere Wartezeit im System 
W=LiA 


3.3 Die M/M/1/K-Warteschlange 


Diese Warteschlange besitzt Anfrage- und Service- 
Rate nach Markovian, einen Bediener und K Benutzer. 
Die Gleichungen sind wesentlich komplexer, weil die 
Zahl der Prozessoren im System endlich ist. Während W 
in den ersten beiden Warteschlangen eine Funktion von 
A und u ist, ist es bei dieser Warteschlange zusätzlich 
eine Funktion der Anzahl der Prozessoren am Bus K und 
von der Anzahl der Prozessoren im System J (wartend 
oder bedient). 

Bus-Verkehrsintensität: 





o = Mu 
Mittlere Anzahl der blockierten Prozessoren im System: 
— Su N 
y s- — 
„a (K-i)! 
n K! 
(0) KT 
2 (K-]i 
Mittlere Wartezeit im System: 
W=LA. 


4 Numerische Berechnung 
der drei Warteschlangen 


Mit den hier angegebenen Gleichungen kann die 
Anzahl der Prozessoren in einem System (L) und die 
mittlere Wartezeit (W) nun für jede der drei Warte- 
schlangen als Funktion der Eingangsvariablen A, u und 
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N bestimmt werden. Allerdings ist dabei Voraussetzung, 
daß diese Werte in numerischer Form vorliegen (X ist die 
mittlere Häufigkeit der Anfragen, u die mittlere Service- 
rate und N die Anzahl der mit dem Bus verbundenen 
Prozessoren). In diesem Beispiel wurden für N entweder 
die Werte 3 und 16 gewählt, das sind die maximalen 
Anzahlen, die jeweils vom seriellen und parallelen 
Arbitrationsschema des Einplatinencomputers SBC-86/ 
12 unterstützt werden, oder, wenn es für die Warte- 
schlange erforderlich ist, unendlich. 

Die Service-Rate u ist abhängig von Anwendung sowie 
Architektur und als Kehrwert der mittleren Service-Zeit 
T; definiert. Die verschiedenen Warteschlangen besitzen 
exponentielle, konstante oder Gamma-Verteilung. Um 
die Berechnung zu vereinfachen und numerische Ergeb- 
nisse zu erzielen, wurde eine hypothetische Applikation 
vorausgesetzt, bei der im Mittel zwei Worte transferiert 
werden. Für das MMPS SBC-86/12 beträgt die Service- 
Zeit typisch 4 us. Daraus folgt, daß die Servicerate u für 
die konstante und exponentielle Verteilung 250 000/s 
beträgt. 

Die mittlere Anfragerate X hängt von Anwendungspro- 
gramm und der Zahl der zu transferierenden globalen 
Variablen ab. X muß als unbekannte Eingangsvariable 
behandelt werden. In Wirklichkeit wird in allen Dia- 
grammen die Bus-Verkehrsintensivität o = Au (anstelle 
X) benutzt, um die Abzisse zu normieren und das Pro- 
blem leichter handhabbar zu machen. 

Die Ergebnisse der numerischen Berechnung sind in 
einer Grafik (Bild 2) zusammengefaßt, in der die mittlere 
Wartezeit für jede Wartschlange als Funktion der Ver- 
kehrsintensivität o dargestellt werden. 


5 Simulation eines TSCB-Systems 


Um die Leistung zu analysieren und einen Bezugswert 
für den Vergleich der theoretischen Ergebnisse, die im 
vorhergehenden Abschnitt gewonnen wurden, zu 
haben, wurde ein Computermodell zur Simulation des 
TSCB-Systems entwickelt. 

Das Multiprozessor-System SBC-86/12 (Bild 3) kann, 
wie bereits in Teil 2 beschrieben, serielle und parallele 
Arbitration verwenden. Wie in Bild 2 des 2. Teils darge- 
stellt, kann die serielle oder „Daisy-Chain“-Arbitration 
ohne externe Logik implementiert werden, aber das 
System ist auf eine maximale Anzahl von drei Prozesso- 
ren bei einem Bustakt von 10 MHz beschränkt. Zentrale 
oder parallele Arbitration (Bild 3 im 2. Teil) erfordert 
einen kleinen Aufwand an externer Prioritätslogik, aber 
unterstützt dafür bis zu 16 Bus-Master. Die tatsächliche 
Implementierung der Prioritätsschaltung hat allerdings 
wenig Einfluß auf das Konzept des Simulationsmodells. 

Der Typ SBC-86/12. ist ein Vielzweck-Einplatinen- 
Computer mit allen Mechanismen, die für ein Multi- 
Prozessor-System erforderlich sind. Besonders wichtig 
sind die 32 KByte Pseudo-Dual-Port-RAM, die 16 KByte 
Programmspeicher (ROM) und die Multibus-Interface- 
Schaltungen. Diese sind um den Bus-Arbiter-Baustein 
8289 aufgebaut und stellen die für den Multiprozessor- 
Betrieb erforderliche Arbitrationslogik dar. Das Dual- 
Port-RAM vereinfacht das Problem des Zugriffs auf den 
Speicher des Partners. 

Das Simulations-Modell ist in PASCAL geschrieben, 
wobei auf Anpassungsfähigkeit geachtet wurde. Es ist so 
konzipiert, daß es leicht konfigurierbar ist, so daß ver- 
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schiedene Systeme mit nur einer einfachen Verände- 
rung der Modellkonstanten simuliert werden können. 
Diese Konstanten sind zunächst für ein Multibus- 
System mit SBC-86/12 bestimmt worden. 

Während eines jeden Simulations-Zeitintervalls muß 
das Modell Busanfragen für jeden Prozessor generieren 
und den Bus den anfragenden Prozessoren zuteilen. Zu 
jedem Zeitpunkt ist das System in einem der drei folgen- 
den Zuständen: 1. der Bus ist frei, 2. ein einzelner Pro- 
zessor will auf den Bus zugreifen, 3. mehr als ein Prozes- 
sor wollen auf den Bus zugreifen. Die Arbitrationsrou- 
tine untersucht alle Prozessoren und entscheidet, ob 
einer und welcher Prozessor die Steuerung des Busses 
übernimmt. Den anfragenden Prozessor mit der höch- 
sten Priorität wird jeweils der Bus zugeteilt. Was aber 
geschieht, wenn der Bus gerade belegt ist? 

Wenn einmal ein Prozessor die Steuerung des Busses 
übernommen hat, müssen alle anfragenden Prozessoren 
(unabhängig von der jeweiligen Priorität) warten, bis der 
derzeitige Bus-Master seine Transaktion beendet hat. 
Dann erst übernimmt der anfragende Prozessor mit der 
höchsten Priorität die Steuerung des Busses. 

Während jeder Simulationsperiode bringt das Modell 
den Systemstatus auf den neuesten Stand und speichert 
die Systemparameter für die spätere Analyse: die 
Anzahl der Taktperioden, die ein Prozessor bis zur 
Berücksichtigung wartet, die Anzahl der vorliegenden 
Busanfragen und die Anzahl der Konflikte zwischen den 
anfragenden Prozessoren. Am Ende des Simulations- 
durchlaufs werden diese Daten benutzt, um die Anzahl 
der Prozessoren, die Zugriff erlangen wollten, die Warte- 
zeit, bevor der Zugriff möglich ist, und die Gesamteffi- 
zienz des Systems zu bestimmen. 


Obwohl dieses Modell identische Wahrscheinlichkei- 
ten der Busanfrage für alle Prozessoren voraussetzt, 
kann dieser Zustand leicht auch für andere Anfrage- 
Muster modifiziert werden. Die konstante Service-Rate, 
die in diesem Modell verwendet wird, kann ebenfalls 


leicht in einen realistischen Wert geändert werden, 
außerdem auch die Länge der Datenpakete. 

Das Computermodell (Bild 3) simuliert das auf dem 
SBC-86/12 basierende System in allen Aspekten, insbe- 
sondere in bezug auf das Bus-Anfrage- und -Zuteilungs- 
Protokoll. Es umfaßt sechs Grundmodule, die in der 
folgenden Weise funktionieren: 

Das Initialisierungsmodul setzt die betreffenden Para- 
meter während der Einschaltphase des Systems zurück. 
Das Anfragen-Generierungs-Modul (Request Generation 
Module) erzeugt eine Zufallsrate von exponentiell ver- 
teilten Busanfragen während der Interationsperiode und 
verteilt diese gleichmäßig auf die M Prozessoren in 
Übereinstimmung mit deren Anfrage-Wahrscheinlich- 
keit (die in diesem Modell als einheitlich angenommen 
wird). Die Prozessormodule simulieren die Bus- 
Anfrage- und Prioritäts-Merkmale des SBC-86/12 und 
leitet die Anfragen an das Arbitrations-Modul weiter. 
Diese sind mit dem Simulationstakt synchronisiert und 
werden gemäß der Priorität zugeteilt. Das Bus-Zutei- 
lungs-Signal (Bus Grant) wird an den Prozessor ausgege- 
ben, der die höchste Priorität besitzt. Dieses Signal liegt 
so lange dort an, bis der Bus wieder frei ist. Das Daten- 
Transfer-Modul simuliert die Wort- und Blocktransfer- 
Merkmale des 8086 sowie des Multibusses und erzeugt 
die mittlere Service-Rate eines jeden Prozessors. Das 
System-Status-Modul verfolgt? die verschiedenen 
Systemparameter und berechnet diese aus den Simula- 
tionsresultaten. 

Für jeden Prozessor berechnet das Modell: die Busan- 
fragen, die mittlere und maximale Wartezeit und die 
Effizienz. Für das Gesamtsystem berechnet das Modell: 
die Anzahl der durchgeführten Transfers, das Verhältnis 
der Anfragen-Konflikte, die totale System-Verzöge- 
rungszeit sowie die Effizienz des Gesamtsystems. Die 
Resultate sind in zwei Diagrammen zusammengefaßt 
(Bilder 4 und 5), die die mittlere Wartezeit eines jeden 
Prozessors als Funktion der Bus-Verkehrs-Intensivität 
für 3- und 16-Prozessor-TSCB-Systeme zeigen. 
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Verkehrsintensivität. Der Betrieb erfolgt in „Locked Operation“ und 
mit 4 us mittlerer Service-Zeit 
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Bild 5. Mittlere Prozessor-Wartezeit eines TSCB-Multiprozessor- 
Systems mit 16 Mastern (SBC-86/12) in Abhängigkeit der Bus-Ver- 
kehrs-Intensivität. Der Betrieb erfolgt in „Locked Operation“ und mit 
4 us mittlerer Service-Zeit 
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6 Vergleich der theoretischen Ergebnisse 
mit den Simulationsresultaten 


Die theoretische Betrachtung und die Simulation bie- 
ten wesentliche Einblicke in die Faktoren, die die Lei- 
stung eines TSCB-Multiprozessor-Systems bestimmen. 
Während die theoretische Analyse bewährte Methoden 
auf das TSCB-System zuschneidet, imitiert die Compu- 
tersimulation die tatsächlichen arithmetischen und logi- 
schen Operationen. 


Die Resultate der theoretischen Analyse sind in dem 
Diagramm, in dem W über o aufgetragen ist (Bild 2), 
zusammengefaßt. Keine der Warteschlangen ist ideal, 
weil keine mit priorisierter Arbitration arbeitet, manche 
setzen eine unendlich große Zahl von Benutzern voraus, 
andere exponentielle oder konstante Service-Raten. Die 
ideale Warteschlange wäre vom Typ P/S/V/N, wobei S 
eine spezielle Verteilung ist, die eine realistische 
MMPS-Service-Rate wiederspiegelt und priorisierte 
Arbitration umfaßt. Die dazu notwendigen mathemati- 
schen Methoden sind bereits entwickelt, aber noch nicht 
dokumentiert. 


Die Simulationsergebnisse für 3- und 16-Prozessor- 
TSCB-Systeme (Bilder 4 und 5) zeigen, daß die Warte- 
zeiten W exponentiell mit wachsendem Bus-Verkehr o 
zunehmen. Wenn e sich dem Wert 1 nähert, wird W für 
Prozessoren mit geringer Priorität sehr groß (besonders 
in dem 16-Prozessor-System und das System wird daher 
sehr uneffizient. Aus diesem Grund sollte es das primäre 
Ziel eines jeden Systementwurfs sein, die Bus-Verkehrs- 
Intensivität möglichst weiter unter 1, besser sogar unter 
0,7 zu halten. Alle wiedergegebenen Resultate wurden 
mit einem Modell erzeugt, das mit dem Locked-Bus- 
Konzept arbeitet, bei dem die Zuteilung während Multi- 
Wort-Transfers unterbunden ist. Zukünftig sollen 
Modelle entwickelt werden, die den Bus nach der Über- 
tragung des ersten Wortes wieder freigeben, was für die 
meisten Anwendungen realistischer ist. 

Ein Vergleich der M/M/1/N-Warteschlange mit der 
Simulation zeigt, daß die Kurven in Bild 6 ähnliche 
Trends aufweisen, aber auch merkliche Divergenzen 
zeigen. Das läßt sich hauptsächlich auf die Ungenauig- 
keiten des Modells zurückführen. Das Warteschlangen- 
Modell umfaßt z.B. keine Priorität, keine realistische 
Service-Raten-Generierung und/oder eine endliche 
Anzahl von Benutzern. Das vorliegende Simulationsmo- 
dell bietet keine priorisierte Arbitration bei Multi-Wort- 
Transfers, unterschiedliche Markovian-Anfrage-Muster 
für jeden Prozessor und eine realistische Service-Raten- 
Generierung. Trotzdem ist das Simulationsmodell akku- 
rater und wird deshalb als Referenzkurve benutzt. 

Im einzelnen sind die Resultate nur für Verkehrs- 
Intensivitäten von 0,00 bis 0,90 gezeigt, weil beide 
Modelle bei gesättigtem Bus starke Abweichungen zei- 
gen. Der Grund dafür liegt in der Tatsache, daß die Zahl 
der wartenden Prozessoren stark ansteigt, ohne daß 
gleichzeitig der Verkehr auf dem Bus weiter zunehmen 
kann. Das wiederum führt zu einer Verlängerung der 
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Bild 6. Die verschiedenen Resultate der theoretischen Untersu- 
chung und der Simulation zeigen gute Übereinstimmung. Unter- 
schiede ergeben sich durch die Ungenauigkeiten der verwendeten 
Methoden 





Zeit, die ein Prozessor in einer Warteschleife zubringt 
sowie zu einer Abnahme der Systemeffizienz. 

Man sollte beachten, daß die Systemeffizienz mit der 
Anzahl der Prozessoren zunimmt. Das liegt daran, daß 
jeder Prozessor in gleichem Maße zur gesamten Bus- 
Verkehrs-Intensität beiträgt und das Hinzufügen weite- 
rer Prozessoren die Anfragen-Rate nicht verändert. 
Daher ist es weniger wahrscheinlich, daß der einzelne 
Prozessor vom Buszugriff ausgeschlossen ist, wodurch 
die Effizienz des Gesamtsystems steigt. Das ist allerdings 
nicht der Fall, wenn die zusätzlichen Prozessoren auch 
die gesamte Arbeitsbelastung erhöhen. In diesem Fall, 
der hier nicht näher erläutert werden soll, nimmt die 
Effizienz des Gesamtsystems ab, weil die Anfrage-Rate 
und die Bus-Belegungen zunehmen, wenn die Zahl der 
Prozessoren steigt. 
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Multi-Mikroprozessor-Systeme 
4. Teil: Entwicklungssysteme für Mehrprozessor-Konfigurationen 


Betrachtet man alleine die Hardware, sind die derzeitig 
verfügbaren Multi-Mikroprozessor-Systeme für die 
Realisierung kosteneffektiver Lösungen bei vielen 
Applikationen geeignet. Es sind bereits eine große 
Zahl Einplatinen- sowie Einchip-Computer erhältlich, 
die ein weites Leistungsspektrum bei geringen Kosten 
bieten. Die verschiedenen Systembusse, z. B. VME-, 
S100- und Multi-Bus, unterstützen Multi-Master-Proto- 
kolle und vereinfachen die Implementierung von Multi- 
prozessor-Systemen. Wie aber steht es mit der Ent- 
wicklung von Anwendungs-Software von Mehrfach- 


Die sich ausweitende Anwendung von Mikrocompu- 
tern und die Notwendigkeit, Hard- und Softwareent- 
wicklung zu vereinfachen, führte dazu, daß sich ein 
vollständig neuer Markt für Mikroprozessor-Entwick- 
lungswerkzeuge entstand. Es handelt sich im einzelnen 
um: 

-konventionelle Testgeräte wie Oszilloskope, Logik- 
Analysatoren, Puls-/Takt-/Wortgeneraturen usw. 

- spezielle Test- und Programmiergeräte wie Takt-/Spei- 
cher-/ Mikrocode-Simulatoren, PROM-Programmierer 
usw. 

- konventionelle Mikrocomputer-Entwicklungssysteme 
wie die „Intellec“-Serie (Intel), „EXORciser‘“‘ (Moto- 
rola) usw. 

- spezielle Mikrocomputer-Entwicklungssysteme wie 
„Microscope“ (Intel), „Serie“ 1000 (Millenium) usw. 
- spezielle Hard- und Software-Debugging-Einrichtun- 

gen wie In-Circuit-Emulatoren usw. 

Am weitesten verbreitet sind heute konventionelle 
Mikrocomputer-Entwicklungssysteme (MDS - Micro- 
computer Development Systems), allerdings unterstüt- 
zen diese Geräte in der Regel nur einzelne Prozessoren 
und einen Benutzer. Erst in letzter Zeit kommen 
Systeme auf den Markt, die sich für den Mehr-Benutzer- 
Betrieb eignen. Das „Z-Lab“ von Zilog ist ein Beispiel 
dafür. Aber welche Geräte unterstützen die Entwicklung 
von Systemen mit mehreren Prozessoren? 

Zu den wenigen bislang auf dem Markt erhältlichen 
Einrichtungen zur Entwicklung von Multi-Prozessor- 


prozessoren, dem dazugehörigen Hardware-Debug- 
ging sowie der Hardware-Software-Integration? Nach 
welchen Gesichtspunkten kauft oder entwickelt man 
ein Betriebssystem, das in der Lage ist, Multi-Tasking- 
Operationen auf Mehr-Prozessor-Systemen zu unter- 
stützen, diese Tasks nach einem Zeitplan ablaufen zu 
lassen, die gemeinsamen Ressourcen zu verwalten, 
die Kommunikation zwischen den Prozessoren zu 
synchronisieren, mit der Umgebung in Verbindung zu 
treten sowie Daten mit peripheren Geräten, wie Termi- 
nals, Drucker und Massenspeicher, auszutauschen? 


Systemen gehört der „Multi-ICE 2302“ von GenRad und 

das System 9516 von Millenium [43, 44]. Beide bieten 

umfangreiche Möglichkeiten zur Echtzeit-Hardware- 

Emulation sowie Hardware-/Software-Integration bei 

bereits aufgebauten Multiprozessor-Systemen (siehe 

Kasten: Industriell gefertigte Multi-Mikroprozessor-Ent- 

wicklungssysteme). 

Nicht angeboten werden derzeit Geräte, die es erlau- 
ben, Emulation und Echtzeit-Evaluation im frühen Sta- 
dium der Entwicklung durchzuführen. Dabei könnten 
frühzeitig unterschiedliche Prozessor-Architekturen 
und System-Softwarepakete auf ihre Eignung für eine 
spezielle Anwendung überprüft werden. Außerdem ver- 
einfacht sich Entwurf, Codieren, Testen und Debugging 
parallel ablaufender Applikationsprogramme. Weil von 
der Industrie nach Kenntnis der Autoren kein derartiges 
System angeboten wird, modifizierten sie ein konventio- 
nelles MDS, so daß es die genannten Anforderungen 
erfüllt. Die gesamte Hardware und der größte Teil der 
Software können mit relativ geringem Kostenaufwand 
(etwa 12 000 $ in den USA) erworben werden. Ledig- 
lich die relativ einfache System-Steuersoftware muß 
geschrieben werden. 

Dieser Beitrag soll insbesondere dazu dienen, 

— die Notwendigkeit der Hard- und Software-Werkzeuge 
zur Unterstützung aller Phasen der Multi-Prozessor- 
Entwicklung zu zeigen 

— zu verdeutlichen, daß Entwicklungseinrichtungen wie 
der „Multi-ICE“ von GenRad oder das System 9516 


= 








Industriell gefertigte 


Sowohl GenRad als auch Millenium haben ihren existieren- 
den Entwicklungssystemen für Einzelprozessoren Einrichtun- 
gen zur Multi-Mikroprozessor-Entwicklung hinzugefügt. In 
erster Linie sind das die verschiedenen In-Circuit-Emulatoren 
(ICE), die über den Systembus mit dem Hostcomputer ver- 
bunden sind (Bild X). Jede ICE-Einheit hat Karten, auf denen 
sich zusätzliche Speicher, Emulations- und Debug-Funktio- 
nen, Echtzeit-Tracing (Logik-Analysator) sowie Ereignis- 
Detektion befinden. Eine „Personality-Probe“ verbindet die 
Emulator-Schaltung in jeder ICE-Einheit mit der Platine des 
Zielsystems. Die Software-Entwicklung erfolgt in herkömmli- 
cher Weise auf dem Hostcomputer des Grundsystems. 


Die Systeme von GenRad und Millenium bieten wirtschaftli- 
che und wirkungsvolle Unterstützung beim Hardware-Debug 
und der Hardware/Software-Integration (Tabelle) — allerdings 
nur bei Multiprozessor-Systemen, die bereits aufgebaut sind. 
Werkzeuge zur Unterstützung der funktionellen Entwicklung 
eines Multi-Mikroprozessor-Systems, z.B. Aufteilung des 
Benutzerprogramms in konkurrierende Tasks, Evaluation der 
Interprozessor-Kommunikation oder der Leistungsmerkmale 
alternativer Architekturen, bieten diese Systeme nicht. 
Neben denbeiden bereits erwähnten Produkten ist inzwischen 
ein Entwicklungssystem von Philips auf den Markt gekom- 
men, das ähnliche Eigenschaften wie die Geräte von Mille- 
nium sowie GenRad zeigt [53]. 


Systeme für die Multi-Prozessor-Entwicklung 


Multi-Mikroprozessor-Entwicklungssysteme 












Entwicklungssystem 
(Grundausführung ) 
Gen Rad 2301-9003 
Millenium 9620 





Serieller Bus 







Serieller Bus 
















Slave - Emulator 
Gen Rad 2302-9002 


Slave - Emulator 
Gen Rad 2302-9002 
Millenium ESS Millenium ESS 


Personality-Probe Personality-Probe 


Slave - Emulator 
Gen rad 2302-9002 
Millenium ESS 


Personality-Probe 

















Zielprozessor 
(verschiedene Typen) 






Zielprozessor 
(verschiedene Typen ) 


Zielprozesser 
(verschiedene Typen) 


Ziel -Multiprozessor - System 


Bild X. An den Hostcomputer können mehrere ICE-Einheiten 
angeschlossen werden. Ein Anschlußmodul von jeder Einheit ist 
mit jeweils einer Prozessor-Karte verbunden. Der Hostcomputer 
verwaltet und steuert die Systemoperation, das Benutzer-Inter- 
face und die Anzeige von Daten 





Merkmale 


System 2302 (GenRad) 


9516 (Millenium) 





Unterstützte Architekturen 
Unterstützte Prozessoren 
Anzahl der uPs im System 


die meisten uPs 
bis zu vier 


viele Multiprozessor-Systeme 


viele Multi-Prozessor-Systeme 
die meisten uPs 
bis zu vier 


System-Hardware 

— Hostcomputer und Speicher 
— Terminal 

— Massenspeicher 

— MDS/Emulator-Verbindung 
System-Software 

— Betriebssystem 

— Cross-Assembler 

- Linker, Debugger 

— HLL-Compiler 
In-Circuit-Emulator (ICE) 

— Zahl der erf. ICE 

— Emulation 

— Emulator-RAM 

— Logik-Trace-Umfang 

— Hardware-Breakpoints 


Inform.-Steuer-System: 17 k $ 
Z80, 64 KRAM, 4 KROM 
CRT mit 24 x 80 Zeichen 
8-Zoll-Doppel-Floppy 

(seriell ?) 


UDOS (GenRad) 
ja 


ja 

PASCAL-G (2302-9807) 
Slave-Emulator ! 

einer pro Zielprozessor 
bis 6 MHz, transparent 
32 K/80 ns 

256 Ereignisse/64 Kanäle 
4 verschachtelt u. bedingt 


System 95SP16: 21,5 k $ 
Z80, 40 KRAM, 4 KROM 
VT-100 (24 x 80 Zeichen) 
8-Zoll-Doppel-Floppy 
seriell 


M/PM-Multi-Tasking 
ja 


ja 

PC8080-PASCAL 
Slave-Emulator ? 

einer pro Zielprozessor 

bis 8 MHz, transparent 

32 K/100 ns 

2x 1024 Ereign./80 Kanäle 
einfach/komplex/super/global 





Bemerkungen 


Software für Z8000. 


A-Bereiche, Ereignis-Zählung und externe Ereignisse. 





1) Die Konfiguration besteht aus Slave-Emulator 2303-9002, Prozessor, Interface, Analysator mit 32 KRAM und Personality-Probe sowie 


2) Die Konfiguration besteht aus XS-Emulator (und Pod), Debugger, Analysator (und Tastköpfe) sowie 32-K-Speicherkarten für Z8000. 
3) Hardware-Breakpoints (Adressen- und Steuersignale) mit Verschachtelung und verschiedenen Bedingungen wie z. B. Speicher- und E/ 


4) einfach: Adressen und Operations-Typ; komplex: Adresse, Status, Daten, externe Ereignisse und Bedingungen; super: sequentielle 
Kombinationen einfacher und komplexer Ereignisse; global: jedes einfache, komplexe und globale Ereignis auf vier globalen Leitungen. 
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_ a 77 

Bild Y. Das Multi-ICE-Entwicklungssystem von GenRad umfaßt 
die System-Konsole, ein Doppel-Floppy-Disk-Controller (2301- 
9003) und bis zu vier Slave-Emulator-Einheiten (2301-9001). In 
jeder ist ein Emulator-Board, eine Speicherkarte und eine Platine 
mit dem Logik-Analysator (optionell). Mit dem Emulator ist z. B. 
die Personality-Probe (2302-9011) für den Z8002 verbunden, die 
in die CPU-Fassung des Zielprozessors eingesteckt wird. 

(Foto: GenRad/Future Data/Kontron) 
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Bild Z. Das System 9516 von Millenium besitzt ein Terminal, das 
dem VT-100 ähnelt, eine Station 9520 mit zwei 8-Zoll-Floppy- 
Disk-Laufwerken. Bis zu vier Emulations-Subsysteme (ESS) kön- 
nen an den Bus des Hostcomputers angeschlossen werden 
(zwei direkt, zwei weitere an die Erweiterungs-Box). Jedes ESS 
verfügt über ein Emulator-Board, eine Debug-Platine mit 8 K 
RAM, eine optionelle Echtzeit-Trace-Einheit (RTT) und eine 
Ereignis-Detektierungs-Karte. Außerdem bietet das System 9516 
benutzerprogrammierbare Tasten, Menue-Anzeige des Hand- 
buchs, einen Kommando-Zeilen-Prozessor für schnelle und 
direkte Eingabe (Foto: Millenium/Spezial-Elektronik) 





Steuer- Emulations- 
Prozessor Modul 
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von Millenium zwar leistungsfähige Unterstützung für 
bereits aufgebaute Prozessor-Konfigurationen bieten, 
die anfängliche Entwicklungsphase aber vernachläs- 
sigen 


— die Notwendigkeit für ein Entwicklungssystem gerade 
auch in diesem Projektabschnitt nachzuweisen 


— zu zeigen, wie ein existierendes SMDS in ein MMDS 
umgebaut wird 


- den Bedarf an vollständiger Multiprozessor-System- 
Unterstützung aufzuzeigen, der von der betreffenden 
Industrie noch nicht befriedigt wird. 


1 Merkmale derzeit verfügbarer Entwicklungs- 
systeme für Einzelprozessoren (SMDS) 


Entwicklungssysteme für Einzelprozessoren (SMDS - 
Single Microprocessor Development System) werden 
sowohl von Halbleiter-Herstellern (Intel, Motorola usw.) 
als auch von Meßgeräteproduzenten angeboten (Hew- 
lett-Packard, Tektronix, Philips usw.). Geräte der Halb- 
leiterhersteller unterstützen normalerweise nur deren 
Produkte, während die anderen Systeme für viele 
Mikroprozessortypen geeignet sind [45...52]. 

Ein typisches SMDS für 8- und 16-Bit-Mikroprozesso- 
ren besteht aus einen 8- oder 16-Bit-Hostcomputer, 
einem Doppel-Floppy-Disk-Laufwerk, einem Drucker, 
einem Ein-Ausgabe-Terminal mit Tastatur und Bild- 
schirm. Die erforderliche Standard-Software umfaßt 
Dienst- und Diagnose-Programme, Assembler, Editoren, 
Binder usw. Compiler für Hochsprachen sind meistens 
als Optionen erhältlich. Die gesamte Software läuft auf 
dem Hostcomputer. In-Circuit-Emulatoren sind Zube- 


hör. Ein SMDS führt in der Regel folgende Funktionen 
aus: 
@Entwicklung von Anwendungssoftware auf dem Host- 
computer 
— Schreiben, Editieren, Assemblieren, Binden, Testen 
und Debugging von Benutzerprogrammen 
— Ausführung des kompletten Programms, 
bestimmten Teiles davon oder einer Zeile 
— Anhalten beim Auftreten eines Fehlers, Anzeige des 
Quellen-/Maschinen-Codes, Modifizierung und 
erneutes Ausführen 


eines 


@®Hardware-Test und -Debugging mit dem ICE 

— Ausführung eines Benchmarks auf dem Zielprozes- 
sor, im Ziel- oder Host-Speicher sowie den E/A- 
Einheiten 

— Anzeige und Modifizierung des Inhaltes von Regi- 
stern, Stack-/Speicher-Plätzen 

— Ausführung von Steuer-/Monitor-Code mit dem 
Analvysator, der Breakpoints setzt 


@Hardware-/Software-Integration mit dem ICE 

— Transfer des Anwendungsprogramms vom Massen- 
speicher zum RAM 

— Reset und Initialisierung der Zähler, Zeitgeber, Flags 
usw. 

— Ausführung des Programms Zeile für Zeile und 
Überwachung der Daten-/Steuerungs-Transfers 

— Trace-Programm-Ausführung zum Test auf Fehler, 
bei denen angehalten wird 

— Aktivierung des Interrupts, Überwachung und Spei- 
chern des Status, Sprung in das Unterprogramm 


®Firmware-Generierung 
— Programmierung der 
EPROM). 


Speicherbausteine (PROM, 












Bild 1. Ein typisches 
Entwicklungssystem 
für Einzel-Prozessoren 
und Ein-Benutzer-Kon- 
figurationen ist der Typ 
AMD SYS-8/8 

(Foto: AMD) 
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2 Anforderungen an zukünftige Multi-Mikropro- 
zessor-Entwicklungssysteme (MMDS) 


Multi-Mikroprozessor-Systeme werden sich erst dann 
auf breiter Front durchsetzen, wenn die erforderlichen 
Werkzeuge zur Verfügung stehen, die wenigstens dem 
derzeitigen Umfang der Entwicklungsunterstützung bei 
Einzelprozessoren entsprechen. Das bedeutet, daß ein 
MMDS auch in der Lage sein muß, alle Entwicklungs- 
phasen zu unterstützen. Im einzelnen sind diese Phasen: 


®Entwicklung der Anwendungs-Software 

— Aufteilung der Programme in Concurrent-Tasks, so 
daß 
— die Parallel-Verarbeitungs- und Intertask-Kommu- 

nikation optimiert wird 
— die Tasks die Interface-Standards erfüllen. 

- Schreiben, Assemblieren, Binden, Testen, Debug- 
ging und Verifizierung von Mehrfach-Tasks-Pro- 
grammen, 

— die sequentiell auf einem oder parellel auf N Pro- 
zessoren ausgeführt werden 

— die permanent spezifischen Prozessoren zugeord- 
net sind (im ROM gespeichert) 

— die während der Laufzeit dynamisch einem freien 
Prozessor übergeben werden 

-die durch Semaphore, Flags, Messages usw. 
gesteuert und synchronisiert werden 

@Evaluation, Simulation und Emulation des Zielsy- 
stems 
-Evaluation verschiedener Zielarchitekturen als 
Alternativlösungen in bezug auf 
— Gesamtleitung, also Durchsatz, Effizienz, Verzöge- 
rungen usw. 

- Effizienz der Kommunikations- und Arbitrations- 
Techniken 

- mögliche Fehlfunktionen und Rekonfigurations- 
Pfade 

— Ausführung eines Benchmark-Programms auf dem 
Emulator in Echtzeit 

- Ausführung jeder Anwendungs-Task und des kom- 
pletten Programms auf 
— dem Software-Simulator des Zielsystems 
— dem Hardware-Emulator des Zielsystems 

-Emulieren der Systemoperationen für den Zielpro- 
zessor, Z. B. 

— Starten und Stoppen der Task-Ausführung 
— Herunterladen der Benutzertasks auf einen spezifi- 
schen Prozessor 
— Überwachung der Operation, Anhalten bei Auftre- 
ten eines Fehlers und Anzeige der wichtigen Daten 
@Hardware-Debugging und Hard-/Software-Integration 

- Verfolgung jeder Zuweisung eines Prozessors oder 
des gemeinsamen Speichers 
- Emulation des Speichers von 1...N Zielprozesso- 

ren mit System-Speicher 
— Abbilden des System- oder Emulator-Speichers im 
Zielspeicher 


— Ausführung einer oder N Tasks auf Emulator-Prozes- 
sor(en) der entwickelten Hardware-Umgebung in 
Form 
—- kompletter Task(s) oder als Satz konkurrierender 

Instruktionen 
— bzw. auf spezifischen Prozessoren oder in dynami- 
scher Dispatch-Betriebsart 

— Anhalten beim Auftreten eines Fehlers, Anzeige der 

laufenden Instruktion(en) und 
— Identifizierung der fehlerhaften Task und/oder des 
Prozessors, der diese ausführt 
— Vorsehen von Einrichtungen zur Modifizierung 
des Codes und Restart des Systems 
Ausführung der Benutzer-Tasks in Concurrend- 
Single-Step-Methode durch 
— Einzelschrittbetrieb eines Prozessors, während die 
anderen angehalten werden 
— Einzelschrittbetrieb aller Prozessoren gleichzeitig 
durch Ablaufenlassen einzelner Takt-/Speicher-/ 
Maschinen-Zyklen 
— Überwachung der Multiprozessor-Operationen bei 
normaler und Einzelschritt-Ausführung durch 
Lesen, Anzeigen und Modifizieren 
— der Global-Daten im zentralen oder verteilten 
gemeinsamen Speicher 

— Adressen und Daten auf dem gemeinsamen Bus im 
Einzelschrittbetrieb 

— Semaphore oder Messages in den Mailboxes 


3 Wie man aus einem konventionellen SMDS ein 
MMDS macht 


Sowohl der „Multi-ICE“ (GenRad) als auch das 
System 2302 (Millenium) bieten leistungsfähige Hard- 
ware-Emulation und unterstützen wirkungsvoll die 
Hardware-/Software-Integration. Allerdings können 
diese Geräte, wie bereits erwähnt, nicht für die anfängli- 
che Phase des Multiprozessor-Entwurfs und der -Eva- 
luation verwendet werden. Die Unterstützung der Ent- 
wicklung von Anwendungssoftware, die von diesen 
Geräten geboten wird, beschränkt sich lediglich auf 
Systeme mit einem Prozessor. Außerdem können sie 
Multiprozessor-Architekturen vor der eigentlichen 
Implementierung nicht emulieren, simulieren und eva- 
luieren. 

Gerade für die Anfangsphase des Multiprozessor-Ent- 
wurfs und der -Emulation stehen keine Werkzeuge zur 
Verfügung. Aus diesem Grund wurde bei General Elec- 
tric (USA) ein MMDS implementiert, das folgende Auf- 
gaben erfüllen soll: 

1. Unterstützung der Software-Entwicklung 

2. Evaluation einer Echtzeit-Architektur 

3. Emulation eines Multiprozessors-Systems mit 
gemeinsamem Bus, der im Multiplex-Betrieb benutzt 
wird 

(Siehe auch 2. Teil dieser Aufsatzreihe). Dieses System 

ist ähnlich wie das Ziel-System aufgebaut, aber mit 
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fertig käuflicher Hardware implementiert. Das vorge- 
schlagene MMDS hat nicht die Möglichkeit des Multi- 
ICE-Systems und kann daher weder die Hardware- 
Debugging- noch die Hardware-/Software-Integrations- 
Merkmale erfüllen, die weiter oben zusammengestellt 
sind. Allerdings ist es damit möglich, preiswert und 
schnell Software- und Hardwareentwicklung für Multi- 
prozessoren auszuführen, insbesondere in den frühen 
Evaluations- und Hardware-Entwurfsphasen. Vorteil 
des vorgeschlagenen MMDS ist, daß es durch Hinzufü- 
gen verschiedener Einplatinen-Computer, die dem Ziel- 
System ähnlich sind, und System-Steuersoftware zu 
einem konventionellen SMDS mit Standard-Systembus 
und freien Einschubmöglichkeiten im Chassis realisiert 
werden kann. In den meisten Fällen ist ein solches 
System bereits bein Anwender vorhanden. 

Die meisten Entwicklungsarbeiten für Multiprozessor- 
Anwendungssoftware können mit den Standard-Pro- 
grammpaketen des SMDS ausgeführt werden, besonders 
dann, wenn man eine Hochsprache benutzt. Das wich- 
tigste Merkmal des vorgeschlagenen MMDS ist hingegen 
die Fähigkeit, eine Emulation des Zielsystems auf käuf- 
lich verfügbarer Hardware durchführen zu können, 
bevor die Hardware des Anwenders konstruiert wurde. 
Multitask-Benutzerprogramme können beispielsweise 
in Echtzeit auf dem Zielcomputer ausgeführt werden, 
indem andere Techniken zum Transfer von Daten zwi- 
schen den Prozessoren und/oder zur Arbitration, ein 
zentraler oder verteilter gemeinsamer Speicher usw. 
Verwendung finden. Auch können verschiedene Ziel- 
prozessoren in einer realistischen Multiprozessor- 
Umgebung durch Ausführung von Benchmark-Program- 
men untersucht werden. 


Das vorgeschlagene MMDS ist mit dem konventionel- 
len SMDS SYS-8/8 von AMD implementiert. Die Grund- 
ausführung umfaßt einen Einplatinen-Hostcomputer auf 
der Basis der CPU 8080, einen 64-KByte-Schreib-Lese- 
Speicher sowie einen Floppy-Disk-Controller. Diese 
Systemgruppen sind über einen Multibus miteinander 
verbunden (Bild 2). Im Chassis des SYS-8/8 sind vier der 
insgesamt sieben Einschübe für Erweiterungen freigelas- 
sen. Drei davon werden zum Aufbau eines Multiprozes- 
sor-Systems auf Basis der CPU Z8000 benutzt. Dazu 
werden die Multibus kompatiblen Einplatinen-Compu- 
ter AM-96/4116 eingeschoben. Durch diese Erweiterung 
wird das SMDS zu einem MMDS. Außer wenigen Vor- 
kehrungen (erstmaliges Setzen der Schalter und Draht- 
brücken zur Festlegung der Adreßbereiche usw.) sind 
keine Hardware-Modifikationen notwendig. Ähnliches 
trifft für die Software-Unterstützungspakete zu. Erfor- 
derlich ist allerdings neue Software für die Systemsteue- 
rung des Hostcomputers. Außerdem muß der Monitor 
des Zielprozessors umfangreichen Modifikationen 
unterzogen werden. 


4 Software: Schlüssel zur Systemmodifikation 


Das Hinzufügen mehrerer Ziel-Prozessoren in Form 
der Einplatinen-Computer zum konventionellen Ent- 
wicklungssystem führt zu einer Multi-Prozessor-Konfi- 
guration (Bild 3), bei der der Multibus die Verknüpfung 
übernimmt. In einem solchen System sind ein zentraler 
gemeinsamer Speicher (64-Kbyte-RAM-Karte) sowie 
verteilte Speicher (32 KByte Dual-Port-RAM, auf jeder 





Erweitertes SYS-8/8-System 


Laufwerk 1 
E 
Laufwerk 2 








BE. OEM System 


Bild 2. Das System wird durch drei Einplatinen-Computer vom Typ AM-96-4116 erweitert 


Multi-Prozessor-Emulator, Zielprozessoren 
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AM-96/ 1000 


Bild 3. Im beschriebenen MMDS 
sind Host- und Ziel-Prozessor 
über den Multi-Bus und den ge- 
| meinsamen Zentralspeicher mit- 
einander verbunden 


Zielprozessor 
AM-96/ 14116 





Zentralspeicher 
64 KByte RAM 


(32 K Byte DP-RAM) 





Disk -Controller 
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Flatine AM-96/4116) vorhanden. Der Host-Prozessor 

kann nur auf den Zentralspeicher zugreifen, während 

die Zielprozessoren Zugang zum zentralen und verteil- 
ten gemeinsamen Speicherbereich haben. 

Um fehlerfreien Betrieb erreichen zu können, müssen 
folgende Softwareteile zusätzlich vorgesehen werden: 
1. System-Steuer-Routinen zur Anpassung der Benut- 

zerschnittstelle an die konkurrierende Umgebung der 

mehrfach vorhandenen Zielprozessoren. 

2. Interface-Routine zwischen dem System-Controller 
und dem Betriebssystemkern VRTX (Versatile Real 
Time Executive). 

3. Bibliotheks-Routinen zur Unterstützung des Benut- 
zers beim Schreiben von Anwendungsprogrammen 
für Multiprozessor-Umgebungen. 

Das Verständnis der gegenseitigen Beziehungen dieser 
Programmroutinen mit dem Betriebssystem des Host- 
computers sowie den Benutzer-Tasks und VRTX-Kern 
der Zielprozessoren ist ebenso wichtig, wie die Kennt- 
nis, in welchem Speicher diese abgelegt sind. Man muß 
unterscheiden zwischen Nur-Lese- und Schreib-/Lese- 
Speicherbereichen auf der Host-Prozessor-Karte, dem 
Zentralspeicher und den N Zielprozessor-Platinen (Bild 
4). 

Bei dem hier vorgeschlagenen MMDS befinden sich 
die Steuerroutinen des Hostprozessors sowie die Mail- 
boxes für die Kommunikation zwischen den Prozesso- 
ren im Zentralspeicher auf der 64-KByte-RAM-Platine. 
Die Betriebssystem-Software (Monitor für Benutzer-E/A) 
ist in einem 2-KByte-EPROM untergebracht. Die Benut- 
zer-Task und die Bibliotheks-Routinen (die an die 
Benutzer-Task angehängt sind) des Zielprozessors befin- 
den sich in den 32-Kbyte-Dual-Port-RAMs, das Betriebs- 
system (Monitor plus VRTX-Kern) in einem 4-KByte- 
EPROM. Diese Aufteilung ist notwendig, weil der Host- 
Prozessor selbst über kein RAM verfügt und nur 64 
KByte Speicher adressieren kann. 

Der Hostprozessor lädt die Benutzer-Tasks aus dem 
Plattenspeicher in den Zentralspeicher. Von dort wer- 
den sie in die Dual-Port-RAMs der Zielprozessoren 
transferiert. Der Benutzer kann die Ausführung in jedem 
Zielprozessor starten und stoppen, indem er die „Create/ 
Delete“-System-Steuer-Routinen benutzt. In ähnlicher 
Weise kann der Benutzer Tasks zurückstellen, wieder- 
aufnehmen und anfordern, wobei die bewährten Inter- 


face-Routinen, die die Steuerung an das VRTX überge- 
ben, zur Anwendung kommen. Mit Systemrufen und der 
Unterstützung der Bibliotheks-Routinen können Benut- 
zer-Tasks auch VRTX-Routinen aufrufen. Die gesamte 
Kommunikation innerhalb des Zielprozessors wird über 
Mailboxes im gemeinsamen Zentralspeicher ausgeführt, 
kann aber auch über die Dual-Port-RAMs geschehen. 


5 Beispiele 


Um die gegenseitigen Beziehungen der verschiedenen 
Softwareeinheiten untereinander zu verdeutlichen, 
wird im folgenden der Betrieb des vorgeschlagenen 
MMDS anhand von drei Beispielen dargestellt. 


5.1 Laden einer Benutzer-Task von der Platte in den 
Speicher des Zielprozessors 


Der Ladeprozeß wird durch das Kommando „LOAD“, 
das man über das Terminal gibt, gestartet. Als Antwort 
darauf startet der System-Manager SM (der Satz von 
System-Steuer-Routinen, die auf dem Hostprozessor 
ausgeführt werden) einen interaktiven Dialog, bei dem 
der Benutzer folgendes einzugeben hat: 


® Dateiname der Task, die geladen werden soll (z.B. 
TASK-1). Es wird vorausgesetzt, daß die Task als Datei 
auf der Platte gespeichert ist. 


® Nummer des Zielprozessors, auf den die Task geladen 
werden soll, z. B. Nr. 3. 


Nach diesem Dialog beginnt das SM, TASK-1 auf den 
Zielprozessor 3 zu laden. Diese Prozedur umfaßt sechs 
Schritte: 

1. Das SM lädt TASK-1 von der Platte in einen Puffer 
(z. B. Puffer 3) innerhalb des gemeinsamen Zentral- 
speichers (CMM - Central common Memory). 

2.Der SM sendet zur Mailbox 3 im CCM, die dem 
Zielprozessor 3 zugeordnet ist, die folgende Informa- 
tion: 

— die Puffer-Nummer (z.B. 3) im CCM, in der sich 
TASK-1 befindet 
— die Länge dieses Puffers 
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— die Startadresse des Speichers im Zielprozessor 
(DP-RAM, Bild 4) in das TASK-1 geladen werden 
soll 

— das LOAS-Kommando, das die eigentliche Transfer- 
Operation mit folgenden Schritten auslöst: 

3. Zielprozessor 3 liest die Information aus seiner Mail- 
box 3 (Puffer-Nummer, Puffer-Länge, Startadresse). 
4. Zielprozessor 3 kopiert TASK-1 aus dem Puffer 3 im 

CCM in sein DP-RAM. 

5. Zielprozessor 3 sendet eine Antwort-Message an die 
Mailbox 3, um das Ende der Operation anzuzeigen. 
6. SM findet die Antwort-Message in der Mailbox 3 und 

beendet die Lade-Operation. 


5.2 Erzeugung einer Benutzertask unter der Steuerung 
des Haupt-Terminals 





Zweck dieser Operation ist die Information des 
Betriebssystem-Kerns VRTX des Zielprozessors, daß 
eine Task erzeugt werden soll, d.h. gesteuert werden 
muß. Die Operation wird durch ein CREATE-Kom- 
mando gestartet, das über das Hauptterminal einzuge- 
ben ist. Als Antwort darauf startet der SM einen interak- 
tiven Dialog auf dem Haupt-Terminal, indem der Benut- 
zer folgende Angaben machen muß: 

1. Die Nummer des Zielprozessors, auf der die Task 

erzeugt werden soll, z.B. 2 
2. die Nummer der Task, z.B. 17. 

3. die Priorität der Task, z.B. 12 


4. die Startadresse der Task, z. B. B000, d. h. die Adresse 
des ersten ausführbaren Codes der Task im Zielpro- 
zessor-Speicher. 

Das CREATE-Kommando sowie die Informationen der 
Schritte 2 bis 4 werden vom SM zur Mailbox 2 gesendet. 
Zielprozessor 2 findet das Kommando in Mailbox 2 und 
ruft VRTX auf, das wiederum die Task 17 mit der Priori- 
tät 12 und einer Anfangsadresse B000 erzeugt und eine 
Message zurücksendet, wenn diese Operation erfolg- 
reich (oder nicht) ausgeführt ist. Diese Message erhält 
die Mailbox 2, wo sie vom SM gefunden und weiterver- 
arbeitet wird. Der SM informiert darauf den Benutzer 
durch Anzeige des Ergebnisses der CREATE-Operation 
auf dem Haupt-Terminal. 


5.3 Zurückstellen einer Benutzer-Task, wenn die Mail- 
box leer ist 


Es sei vorausgesetzt, daß Task 17 auf dem Zielprozes- 
sor 2 läuft und an einem Punkt angelangt ist, an dem sie 
Informationen von einer anderen Task benötigt, z.B. 
Task 9, die auf demselben oder einem anderen Prozessor 
läuft. Diese Informations-Transfer-Operation wird über 
eine Mailbox ausgeführt, die sich im CCM befindet. In 
der Programmiersprache C ist diese Operation mit fol- 
gendem Statement beschrieben: 
message = pend(mailboxadtress, error); 

Die Funktion „pend“ findet die gewünschte Mailbox 
unter „mailboxadress“ und gibt die Information aus 





Floppy - Disk- 
Doppel -Laufwerk 


Haupt - Terminal, 
Steuertastatur 


E/A und - weitere Host-Routinen 
Steuerung -Puffer 
“- Serielle E/A = 

- Parallele E/A 


usw System-Steuer-Routinen 


- Start/Stop-Zielpr 
- Laden Zielspeicher - 
- Floppy-Disk-Interface - 
- Anzeige 

- Multiprozessor- Debug 
-USW 


Betriebssystem 
- Benutzer -E/A 
- Interrupt-E/A 


- USW -Interface-Kern 


Mailbox 1 
Mailbox 2 
Mailbox N 


Host - Prozessor -Karte zentrale 64-K Byte - Speicher - 


karte 





Bibliotheks - 
routinen 


Benutzer-Tasks 
- Task 1 
- Task 2 


Interface - 
Routinen 
- Load 

- Create 
- Delete 


32-K Byte- DPRAM 





Zielprozessor -Karte (Eine von mehreren) 


Bild 4. Beziehungen der verschiedenen Software-Blöcke des MMDS 


Monitor 
- Benutzer -E/A 
- Interrupt -E/A 


E/A + Steuerung 
- Serielle E/A 
VRTX-Kern Parallele E/A 

Task-Verw Takt 
Speicher-Verw Zahler/Zeitgeber 
Takt -Verw Interrupt 
Task-Komm 
Task -Synchr 
E/A - Verw 
MMPS-Verw 


4-K Byte-EPROM 


Parallel-E/A 
-Interrupts 
-Reset usw 








34 


dieser Mailbox in die Variable „message“. Task 17 kann 
sie jetzt benutzen. 

Im Fall, daß die Mailbox leer ist, stellt die Funktion 
„pend“ Task 17 zurück. Diese wird von VRTX erneut 
aufgerufen, wenn die Information vorliegt, daß die erfor- 
derliche Message in der Mailbox ist. 


6 Erforderliche Steuersoftware 


Die Orginal-Software des SMDS besteht aus einem 
Monitor oder Debugger, die wiederum einfache RS-232- 
Benutzer-Interface-, Register/Speicher-Inspektions/ 
Modifikations-Routinen usw. umfassen. Beim vorge- 
schlagenen MMDS müssen die System-Steuerroutinen 
des Hostcomputers noch weitere Aufgaben erfüllen. Ins- 
besondere muß es die Benutzer-Tasks an den VRTX- 
Kern anpassen. Aus diesem Grund müssen noch fol- 
gende Routinen geschrieben werden: 


® Start-/Stop-Routine für den Zielcomputer 
zum Starten und Anhalten der Ausführung von Benut- 
zer-Tasks auf jedem der drei Zielprozessoren durch die 
Systemsteuerroutinen 

® Lade-Routine für den Zentralspeicher 
zum Laden von Benutzer-Tasks von der Platte in den 
Zentralspeicher, initialisiert durch das Benutzer-Ter- 
minal und vom Host-Computer gesteuert 

© Datei-Handling-Interface-Routine 
zum Bereitstellen der Unterstützungsfunktionen, die 
erforderlich sind, um Platten-Files durch Benutzer- 
Tasks des Zielprozessors öffnen, lesen, beschreiben 
und schließen zu können 

© Display-Fenster-Erzeugungs-Routine 
zum Anzeigen von Zahlen und Texten von Tasks, die 
auf jedem der drei Zielprozessoren ausgeführt werden, 
in vorher festgelegten Bereichen des Bildschirms 

© Kern-Interface-Routinen 
zum Bereitstellen der erforderlichen Unterstützungs- 
funktionen für Systemaufrufe der Benutzer-Tasks an 
das Betriebssystem sowie für die Rückkehr von Sy- 
stemaufrufen. Folgende Multi-Tasking-Routinen wer- 
den unterstützt: 
- Erzeugen, Löschen, Zurückstellen und Wiederauf- 

nehmen von Tasks 


— Initialisierung des Ladevorganges, der die Benutzer- 
Tasks aus dem gemeinsamen Speicher in ein Dual- 
Port-RAM bringt 

— Aussenden von Messages usw. 
® Multitasking-/Multiprozessor-Debug-Routinen zum 

Lesen, Anzeigen und Modifizieren von Daten oder 

Instruktionen in Registern oder Speichern, auf dem 

System- oder lokalen Bus usw., nachdem das System 

angehalten oder in den Einzel-Schritt-Betrieb versetzt 

worden ist. 

Die grundsätzliche Philosophie beim Debugging ist 
die Ausführung von mehreren Tasks auf Multi-Prozes- 
sor-Systemen nur, nachdem die eigentliche Task auf 
einem Einzelprozessor getestet und fehlerfrei gemacht 
worden ist. 

Es ist zu erwarten, daß die System-Steuerroutinen, 
wie sie hier beschrieben sind, sich verändern werden, 
wenn die Verfahren und Methoden für Entwicklung, 
Test und Debugging von Multiprozessor-Software und 
Hardware für das vorgeschlagene System verändert wer- 
den. Existierende Routinen werden verbessert, neue 
hinzugefügt (besonders, um die Möglichkeiten zum Feh- 
lerbeseitigen zu verbessern), und alle Routinen werden 
auf mehr gemeinsame Unterprogramme zurückgreifen. 


7 Ersatz des Ziel-Computer-Monitors durch VRTX 


Ein Platinen-Computer wie z.B. der Typ AMD AM- 
96/4116 oder Intel SBC-86/12 verfügen über einen einfa- 
chen Monitor (System-Steuersoftware) der allgemeine 
Debug-Funktionen wie Lesen, Anzeige und/oder Modifi- 
zieren von Registern oder Speicherplätzen umfaßt. Diese 
Platinen bieten auf einfache Kommunikation zwischen 
Prozessoren über zentrale oder verteilte gemeinsame 
Speicher. Allerdings können diese Programme keine 
Mehrfach-Tasks verarbeiten oder Kommunikation zwi- 
schen Prozessoren synchronisieren. Außerdem muß das 
gesamte Interrupt-Handling, Echtzeitfunktionen, Spei- 
cherzuweisungen und Zeichen-E/A durch Benutzer- 
Software ausgeführt werden. 

Während des letzten Jahres sind verschiedene 
Betriebssystemkerne auf den Markt gekommen, die als 


Tabelle der Betriebssysteme, die als Festwertspeicher erhältlich sind 


Parameter 80130 (Intel) 
Zielprozessor 8086/186/286 
Umfang/Medium/Erweiterbarkeit 16 K/ROM/Fest 
Kompatibilität zu RMX-86 
Task-Verwaltung ja 

Semaphore ja 

Messages ja 
Interrupt-Handling ja 
Speicher-Zuweisung ja 


Erzeugen/Löschen von Tasks 


ja 
Konfigurations-Methode Daten-Basis-SW 


Festkörper-Bausteine verfügbar sind (Tabelle). Der 
ZRTS (Zilog) VRTX (H&R) 
Z8000/1/3/4 8086/Z8000/68000 
4 K/EPROM/Erw. 4 K/EPROM/Erw. 
nein nein 
ja ja 
ja kein Standard 
ja nein (Mailboxes) 
ja ja 
ja ja 
ja ja 


Konfigurierungs-SW 14 Register 
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Zweck dieser Kerne ist die Anpassung von Anwen- 
dungs-Software in standardisierter Weise (hardware-/ 
software-unabhängigB an Mikroprozessor-Hardware. 
Dazu wird ein sogenannter Betriebssystem-Bus verwen- 
det. Dem Benutzer bieten sich mit diesen Kernen 
bewährte und erprobte Routinen für die meisten 
gebräuchlichen Multitasking-Systemfunktionen. 

In dem hier vorgestellten Beispiel wurde VRTX (Ver- 
satile Real Time Executive) gewählt, um den Monitor 
des AM-96/4116 zu ersetzen, insbesondere weil dieses 
über Mechanismen verfügt, mit denen man den existie- 
renden Vorrat an Kern-Routinen durch spezielle Benut- 
zerroutinen erweitern kann. Obwohl VRTX bereits über 
eine umfangreiche Menge von Multi-Tasking-Routinen 
verfügt, unterstützt die vorliegende Version keine Multi- 
Prozessing-Systemoperation. Deshalb wurde eine Spe- 
zial-Routine für die Synchronisation und die Ausfüh- 
rung von Mehrfach-Tasks auf Multi-Prozessor-Systemen 
zum existierenden Vorrat an Kernroutinen hinzugefügt. 
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Mit den beschriebenen Modifikationen und wenigen Einplati- 
nen-Computern können die meisten Ein-Prozessor-Entwick- 
lungssysteme auch zur Unterstützung von Multi-Prozessor- 
Operationen verwendet werden, insbesondere bei solchen 
mit gemeinsamem Bus im Multiplexbetrieb (TSCB). Die 
Anzahl der Prozessoren in einem solchen System ist in erster 
Linie durch die Menge der noch freien Einschubmöglichkeiten 
im Entwicklungsgeräte-Chassis und durch das Prioritäts- 
Codierungs-Verfahren beschränkt. Die folgenden Schritte fas- 
sen die notwendigen Vorgänge zur Implementierung des 
MMDS zusammen: 


@ Kauf folgender Gegenstände: 

—- Konventionelles uP-Entwicklungssystem mit Multi-Master- 
Bus 

- sowie MDS-Software-Unterstützung und Hochsprachen- 
Compiler 

- N Bus-kompatible Einplatinen-Computer der uP-Familie des 
Zielrechners 

— Betriebssystemkern im ROM, z. B. VRTX 


@ Initialisierung und Inbetriebnahme des Systems 

— Zusammenbau von Host-Computer, gemeinsamem Spei- 
cher und E/A-Platinen 

— Zusammenbau der Ziel-Computer (z.B. Festlegen des 
Adreßraumes durch Schalter oder Drahtbrücken) 

- Einschub der Zielcomputer in die freien Plätze des SMDS 

— Ausführung einzelner Testroutinen auf jedem Prozessor 


@ Schreiben der System-Steuerroutinen für den Hostrechner 
zum 
— Laden von Anwendungsprogrammen in den Zielprozessor 





Wie stellt man ein preiswertes 
Multiprozessor-Entwicklungssystem zusammen? 


- Aufnahme und Anzeige von Daten aus Mailboxes im 
gemeinsamen Speicher 

— Rücksetzen und Synchronisieren der Frame-Rate des Ziel- 
prozessors 

-Anhalten bei einem Fehler und Anzeigen der kritischen 
Daten usw. 


© Hinzufügen eines Multi-Tasking-Kerns, so daß 

- jeder Prozessor mehrere Tasks erzeugen, aussetzen und 
ablaufen lassen kann 

— Speicher, E/A und andere gemeinsame Ressourcen verwal- 
ten kann 

— Echtzeit-Takt- und Interrupt-Funktionen steuern kann 


© Hinzufügen von Multiprozessor-Funktionen zum Multi-Tas- 
king-Kern 

— Synchronisierung der Kommunikation zwischen den Pro- 
zessoren 

— Umsetzen logischer in physikalische Adressen 


® Überprüfen der Funktion mit Beispielprogramm 

- Ausführung des Demonstrationsprogramms auf einem Pro- 
zessor ; 

—- Ausführung des Demonstrationsprogramms auf mehreren 
Prozessoren 


@ Entwicklung von Anwendungs-Software fürjeden Prozessor 
unter Verwendung von 

— Standard-Entwicklungssystemen-Unterstützungs-Software 

- Konventionellen Editoren, Assemblern, Compilern und Bin- 
dern 

— Assemblierung und HLL-Programmierung 

— einfachen und mehreren Tasks mit Betriebssystem. 
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Dr. Egon Hörbst, Dipl.-Ing. Anton Sauer 
Ein Multi-Mikrocomputer-System 


am Arbeitsplatz 
1. Teil: Konzept und Zielsetzung 


Der Einsatz von Multi-Mikrocomputer-Systemen ist 
in dem weiten Bereich von der intelligenten 
Schreibmaschine bis zur kommerziellen oder indu- 
striellen Datenverarbeitung möglich und sinnvoll — 
in Zukunft auch in Großrechnersystemen. Die Vor- 
teile dieser Strukturen sind — nach dem großen 
Einsatzspektrum — die funktionelle Aufteilung von 
Hardware und Software, die Modularität des Sy- 
stemaufbaues und die dadurch bedingte Erweiter- 
barkeit. Die Aufgaben reichen von der Textbearbei- 


1 Einsatzgebiet von Multi-Mikrocomputer- 
Systemen und Anforderungen 


Mehr-Computersysteme auf der Basis von Mikro- 
prozessoren können überall dort eingesetzt werden, 
wo eine Aufteilung der Software auf selbständige 
Hardwarekomponenten (Mikrocomputer) zulässig ist. 
Der funktionelle Ablauf kann dabei zentral gesteuert 
erfolgen oder von einer Systemkomponente über- 
nommen werden |1|. 

Mögliche Ausführungen solcher Strukturen, be- 
stimmte Lösungsvorschläge und Anordnungsvor- 
schläge sind in |2, 3, 4) enthalten, wobei sich die Aus- 
sagen bezüglich der Brauchbarkeit der Struktur auf 
bestimmte ausgewählte Beispiele beschränken. 

Beispiele sind Einsatzmöglichkeiten 
@ in Informationssystemen (Management, Leitzentra- 

len), 
® im gesamten Gebiet der mittleren Datentechnik 

(Arbeitsplatzcomputer, Bürocomputer), 
® in künftigen Großrechnersystemen |5). 

Diese Art der Informationsverarbeitung istauch von 
Monoprozessorsystemen her bekannt. Mehrrechner- 
systeme bieten jedoch einige Vorteile. Sie liegen: 
® in der Modularität des Systemaufbaues und der da- 

durch bedingten Erweiterbarkeit, 
® iin der funktionellen Aufteilung von Hard- und 

Software 
® im großen Einsatzspektrum. 

Daraus folgt für Mehrrechnersysteme, daß die Sy- 
stementwicklung gezwungenermaßen strukturiert er- 





tung im Schreibbüro bis zur Systementwicklung in 
Labor und Prüffeld. Im 1. Teil dieser fünfteiligen 
Aufsatzreihe, die von einem siebenköpfigen Auto- 
ren-Team aus den Forschungslaboratorien der Sie- 
mens AG verfaßt wurde, werden nach der grund- 
sätzlichen Vorstellung von Hard- und Software 
eines Mehrrechnersystems am Arbeitsplatz die Vor- 
teile bei der Systementwicklung, beim Kunden und 
bei der Systembetreuung durch Hersteller und Ver- 
teiler diskutiert. 


folgen muß und daß der Test der Einzelkomponenten 
weitgehend unabhängig erfolgen kann. 

Für ein Rechnersystem, das am Arbeitsplatz einge- 
setzt wird, ergeben sich Anforderungen, die vom An- 
wender (Sachbearbeiter, Sekretärin) gestellt werden 
und aus den Aufgaben resultieren, die mit einem sol- 
chen Arbeitsplatzcomputer gelöst werden sollen. 


Beispiele dafür sind: 

@ Textbe- und -verarbeitung 

® Daten speichern, ändern, suchen, sortieren, aufbe- 
reiten, abrufen, anzeigen 

® Kommunikation mit anderen Systemen (Anschluß 
an Datennetze, an andere Rechner, Verbindung sol- 
cher Systeme untereinander) 

® Entwicklung von Systemen (Hardware, Software 
von Rechnern, Anwendersoftware, grafische Da- 
tenverarbeitungssysteme, usw.) 

@ Test von Systemen. 


Die Thematik der Aufsatzreihe ist folgendermaßen un- 
terteilt. 


1. Teil: Konzept und Zielsetzung 
2. Teil: Bus-Strukturen für Mehrrechnersysteme 
3. Teil: Verteiltes Betriebssystem einer Mehrrechner- 


struktur 
4. Teil: Praktische Ersatzbeispiele eines Mehrrechner- 
systems als Terminal 


5. Teil: Entwicklung, Test und Aufbau 
von Mehrrechnersystemen 
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Die Art dieser Beispiele zeigt, daß ein derartiger Ar- 
beitsplatzcomputer in einem Schreibbüro, Sekretariat, 
in Vertriebs-, Fertigungs- oder Entwicklungsabteilun- 
gen eingesetzt werden kann (siehe Teil 4). Ein Vorteil 
des Einsatzes einer Mehrrechnerstruktur in solch un- 
terschiedlichen Umgebungen liegt eben darin, daß 
nur ein einziges Grundsystem zu entwickeln und her- 
zustellen ist, das in unterschiedlichen Ausbaustufen 
mit unterschiedlichen Softwarepaketen für diesen 
weiten Bereich geeignet ist. 


2 Konzeption 
eines Multi-Mikrocomputer-Systems 


Um die genannten Anforderungen realisieren zu 
können, ist es notwendig, eine Aufteilung des Ge- 
samtsystems (Software und Hardware) in einzelne 
Funktionen vorzunehmen. Eine Aufteilung in Funk- 
tionen und damit die Übertragung der Funktionen auf 
eine Mehrrechnerstruktur wird aus einem Monorech- 
nersystem abgeleitet. In der Tabelle sind einige Funk- 
tionen ausgewählt und deren Aufgaben angegeben. 


Aus der funktionellen Aufteilung läßt sich eine Ein- 
teilung der in der Tabelle genannten Funktionen in 
drei Ebenen vornehmen: 


@ Dialogebene mit der Dialogfunktion, 


® Kommunikationsebene mit der internen Kommu- 
nikationsfunktion und 


® Funktionsebene mit den restlichen Funktionen 
nach Tabelle (Verarbeitungs-, Ein/Ausgabe-, Datei- 


Tabelle. Auswahl von Funktionen und deren Aufgaben für 

den Arbeitsplatzcomputer 
Dialogfunktion — Maskenaufbereitung 
Benutzerführung 
Eingabeprüfung 


— Übersetzen, Binden.... 
mathem. Funktionen 
Textedition 


Verarbeitungsfunktion 


— Kanalroutinen 
Textaufbereitung 


Ein/Ausgabefunktion für 
periphere Geräte 


— Verwaltung 
Suchen 
Sortieren 


Dateibearbeitungsfunktion 


Diagnose- und Testfunktion — Systemtest 
Erkennung von Hw- und 
Sw-Fehlern 


Maßnahmen zur Fehler- 
behebung 


interne — interner Datenaustausch 

Kommunikationsfunktion Verhinderung von System- 
zusammenbrüchen 

externe — Anschluß an andere Rechner 

Kommunikationsfunktion Prozedurabwicklung 
Textaufbereitung 
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bearbeitungs-, Diagnose-, Test-, externe Kommuni- 
kationsfunktion). 


Zusätzlich kommen noch Benutzer- und Periphe- 
rieebene hinzu. 


Über Benutzer- und Dialogebene wird zu gegebener 
Zeit eine bestimmte Funktion der Funktionsebene 
ausgewählt und über die Kommunikationsebene er- 
reicht. Dort wird die Abarbeitung dieser Funktion ini- 
tialisiert. Während der Abarbeitung dieser Funktion 
sind Kommunikations-, Dialog- und Benutzerebene 
wieder freigegeben für andere Abläufe. 


Ein weiterer Kernpunkt bei der Konzipierung eines 
Mehrrechnersystems ist die Kommunikation der ein- 
zelnen Bestandteile des Systems untereinander. Ei- 
nige Kommunikationsmechanismen sind in Theorie 
und Praxis für Multiprozessorsysteme untersucht und 
beschrieben worden |6, 7, 8, 9). Darüber hinaus wurde 
in |10| eine graphentheoretische Klassifikation nach 
dem Typ der Verbindung zwischen den Knoten vorge- 
stellt und in |11) eine Einteilung nach der Struktur des 
Arbeitsspeichersystems vorgenommen. 


Zur Realisierung der Anforderungen kann man auf 
streng hierarchisch aufgebaute Systeme, wie sie heute 
in der Prozeßverarbeitung noch eingesetzt werden, 
verzichten. Die Hardwarekomponenten von Dialog- 
und Funktionsebene werden dezentral, gleichberech- 
tigt um die Kommunikationsebene angeordnet. Mög- 
liche Architekturen sind dann Ringstruktur, Stern- 
struktur und vermaschte Struktur |10). 


Untersuchungen an einer vermaschten Struktur 
und einer Sternstruktur in einem dezentralen Mehr- 
rechnersystem haben ergeben, daß die Sternstruktur 
der vermaschten hinsichtlich Erweiterbarkeit und 
Flexibilität weit überlegen ist |12|. Hinsichtlich Si- 
cherheit dürfte die Sternstruktur (bei Doppelung) der 
Ringstruktur überlegen sein. In unserem Fall wurde 
deshalb eine Sternstruktur realisiert (siehe auch 
Teil 2). 


3 Systemaufbau 
3.1 Hardwareaufbau 


Die in der Tabelle aufgezählten Funktionen können 
nun auf unterschiedliche Weise auf eine Mehrrech- 
nerstruktur übertragen werden |13|. Gewählt wurde 
eine Aufteilung in verschiedene Ebenen, wie siein |10) 
beschrieben ist. Im einfachsten Fall wird jede Funk- 
tion auf einem eigenen Rechner installiert, so daß 
sich, wenn man Redundanzen berücksichtigt, die 
Struktur in Bild 1 ergibt. 


Die Hardwarekomponenten des Systems (Mikro- 
computer) sind modular aufgebaut: Jeder Rechner ver- 
fügt über ein gleiches Grundmodul. Daneben können, 
abhängig von der Funktion, die dem Rechner zu- 
geordnet ist, Speichermodule und E/A-Module für 
spezielle periphere Anschaltungen dazu gesteckt 
werden. Das Grundmodul besteht aus der CPU-Grup- 
pe, Programm- und Datenspeicher, paralleler und se- 


Peripherieebene 


Funktionsebene 


Bild 1. Aufteilung der 


Kommunikations - 
ebene 


Funktionen auf Hard- 
warekomplexe 


Dialogebene 


Benutzerebene 


rieller Standardschnittstelle und einem Interface zur 
Kommunikation zwischen den einzelnen Rechnern. 

Der Datenaustausch zwischen den Rechnern erfolgt 
über einen gemeinsamen Bus. Es wurde ein hard- 
waregesteuerter Datenaustausch über direkten Spei- 
cherzugriff (DMAJ) realisiert 114. Auf diese Weise sind 
mit heute erhältlichen DMA-Controllern Übertra- 
gungsraten bis zu 1 MByte/s erreichbar. 





Der Start des Gesamtsystems mit den einzelnen 
Komponenten läuft vollautomatisch ab. Das Diagnose- 
und Testsystem liefert am Anzeigefeld eine Aussage 
über die Betriebsbereitschaft des Systems. Eine wei- 
tere Aufgabe des Diagnose- und Testsystems ist die 
Überwachung auf Ausfälle von Einzelkomponenten, 
wobei Fehlermeldungen auf dem Anzeigenfeld ange- 
zeigt werden. 


3.2 Softwareaufbau 


Die funktionale Aufteilung des Systems auf ein- 
zelne Hardwarekomponenten (Mikrocomputer) be- 
deutet eine Zerlegung der Systemsoftware in funktio- 
nell unabhängige Teile, die in ein hierarchisch struk- 
turiertes Niveauschema eingebaut werden |15 (siehe 
Teil 3). 

Ein solches Niveauschema am Beispiel des Arbeits- 
platzcomputers nach Bild 1 ist in Bild 2 wiedergege- 
ben. 


Der Aufbau des Systems beginnt auf der untersten 
Ebene (Hardware-Ebene) mit der lokalen Software, 
z. B. Gerätetreiber. 

Über der lokalen Software befindet sich die Kom- 
munikationssoftware. Die Kommunikationsprozedu- 
ren sind auf allen Rechnern im wesentlichen gleich. 
Damit wird vor allem die Modularität und Erweiter- 
barkeit des Gesamtsystems gewährleistet. Die Kom- 
munikationssoftware erfüllt die Aufgaben der inter- 
nen Datenübertragung und der Rechnersynchronisa- 
tion. 


Das Betriebssystem umfaßt Serviceroutinen für Da- 
tentransport und Programmausführung. Der Zugang 
von der Anwenderebene zur Betriebssystemebene er- 
folgt über die Systemschnittstelle. 


Dialog- 
Funktion 





Mit diesem Hierarchiekonzept und der Unabhängig- 
keit der Programme innerhalb einer Ebene wird eine 
hohe Sicherheit und Flexibilität auch der System- 
software erreicht. 

Die Anpassung an unterschiedliche Einsatzfälle 
und Ausbaustufen ist gewährleistet und wird wäh- 
rend der Systemgenerierung durchgeführt. Dies kann 
durch einen Lade-ROM und durch Einlesen des Be- 
triebssystems von einem externen Speicher, z. B. Dis- 
kette erfolgen. Bei Änderungen in der Konfiguration 
ist dann der entsprechende Datenträger zu ändern. 


4 Zielsetzung 


Drei Hauptziele waren vorgegeben für die Entwick- 
lung eines Arbeitsplatzcomputers auf der Basis eines 
Mehrrechnersystems. Dieses System soll gegenüber 
herkömmlichen Systemen 


@ Vorteile bei der Systementwicklung bringen, 

®@ die Flexibilität des Systemeinsatzes beim Kunden 
gewährleisten und 

© die Wirtschaftlichkeit bei der Systembetreuung 
durch den Hersteller und den Vertreiber erhöhen. 


4.1 Vorteile bei der Systementwicklung 


Durch die funktionelle Aufteilung der Software auf 
gleichartige Hardwaregebilde wird ein modularer Sy- 
stemaufbau gewährleistet. Auf jedem Rechner wird 
ein genau abgegrenzter Softwareteil implementiert. 
Für die Systementwicklung bedeutet dies, daß zwi- 


Verarbeitungs- 
Funktion & 





Bild 2. Struktur der Systemsoftware des Arbeitsplatzcomputers 
nach Bild 1 


39 


schen den einzelnen Funktionen nicht nur klare 
Hardware-Schnittstellen, sondern auch Software- 
Schnittstellen vorhanden sind. 

Ein weiterer Punkt ist die Testsituation bei der Sy- 
stementwicklung. Es muß immer nur die einzelne 
Funktion, das einzelne Modul, das einzelne Gerät 
getestet werden. 


4.2 Flexibilität beim Systemeinsatz 


Geht man davon aus, daß unser Mehrrechnersystem 
mit den aktuellen Anforderungen mitzuwachsen hat, 
dann heißt das, daß das System in seiner ursprünglich 
gewünschten Ausbaustufe nicht für immer eingesetzt 
wird. Ein wichtiger Punkt ist daher die Systemerwei- 
terbarkeit und zwar um mehr oder weniger Funktio- 
nen. Voraussetzung dafür ist die Ladbarkeit der Pro- 
gramme in die einzelnen Rechner. 

Das System ist „vor Ort‘ generierbar. Je nach Aus- 
bau an Rechnern, Funktionen, Peripherie wird das ak- 
tuelle Betriebssystem am Einsatzort generiert. Beim 
Einschalten und Hochfahren des Systems genügt 
dann in jedem Rechner ein Urlade-ROM, die aktuelle 
Systemsoftware wird vom externen Speicher in den 
Schreib-Lese-Speicher der einzelnen Rechner gela- 
den. 


4.3 Wirtschaftlichkeit bei der Systembetreuung 


Der zuletzt genannte Punkt, die Generierbarkeit des 
Systems beim Kunden bringt dem Hersteller und 
Kunden einen großen Vorteil: Die Lagerhaltung wird 
stark vereinfacht, weil sie sich auf die Urlade-ROMs 
und auf ein allgemeines Betriebssystem beschränkt 
und nicht auf Software, die auf den Systemausbau bei 
jedem Kunden zugeschnitten ist. 
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Ein ganz anderer Aspekt ist die Vereinfachung der 
Wartung. Da das System modular aus gleichen Einhei- 
ten aufgebaut ist, wird auch die Wartbarkeit sehr ver- 
einfacht. Der Wartungstechniker wechselt bei fehler- 
haftem Verhalten des Systems einzelne gleichartige 
Platinen aus und kann so den Fehler auf die einzelne 
Baugruppe einschränken. (Die Fehlersuche auf der 
fehlerhaften Baugruppe wird nicht beim Kunden, 
sondern beim Hersteller vorgenommen.) Die Fehler- 
eingrenzung wird — wiederum bedingt durch den mo- 
dularen Systemaufbau - in verschiedenen Stufen vor- 
genommen: Test des Gesamtsystems, des Kommuni- 
kationsteils, des fehlerhaften Rechners (seiner CPU, 
seines Speichers), des fehlerhaften Endgerätes. 


Ein wiederum anderer Aspekt ist das einfache Ak- 
quirieren beim Kunden mit auf die aktuellen Pro- 
bleme des Kunden zugeschnittener Anfangskonfigu- 
ration. Durch die Breite des Einsatzspektrums unserer 
Mehrrechnerstruktur für sehr geringe Anforderungen 
(z. B. intelligente Schreibmaschine) bis zu sehr hohen 
Anforderungen (z. B. Beginn der kommerziellen Da- 
tenverarbeitung) mit ein und derselben Hard- und 
Software (in unterschiedlicher Anordnung) ist es 
möglich, die meisten Probleme des Kunden auf dem 
Gebiet der mittleren Datentechnik zu lösen. 
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2 Teil: Bus-Strukturen für Mehrrechnersysteme 


Multi-Mikrocomputer-Systeme sind in sehr vielen 
Anwendungsbereichen einsetzbar und erfreuen 
sich deshalb bei der Systementwicklung wachsen- 
der Beliebtheit. Um in die verwirrende Vielfalt der 


Ein Kernpunkt bei der Konzipierung eines Mehr- 
rechnersystems ist die Art des Datenaustausches der 
einzelnen Rechner untereinander. Verschiedene 
Übertragungsmechanismen werden angegeben, die 
sich in der Verwendung verschieden komplexer 
Hardware-Hilfsmittel unterscheiden. Grundsätzlich 
kann festgestellt werden, daß unter Zuhilfenahme von 
immer leistungsfähigerer Hardware der Software-An- 
teil bei den Übertragungsprozeduren verringert und 
damit die Übertragungsrate erhöht werden kann. 

Die Architektur eines Mehrrechnersystems wird 
wesentlich durch das Kommunikationssystem be- 
stimmt, das die einzelnen Rechner untereinander ver- 
bindet. Dabei wird insbesondere auf Bus-Systeme ein- 
gegangen. Ein Lösungsvorschlag für den Aufbau eines 
Bus-Systems über direkten Speicherzugriff wird vor- 
gestellt und ausführlich beschrieben. 


1 Allgemeine Übersicht und Abgrenzung 


Computer kann man vereinfacht als Systeme be- 
trachten, die Befehlsströme (Programme) ausführen, 
um Datenströme zu verarbeiten. Entsprechend der 
Anzahl der möglichen Befehls- und Datenströme kann 
man Computersysteme in vier Klassen unterteilen mit 
den Merkmalen |1, 2, 3): 

- ein Befehlsstrom und ein Datenstrom (SISD = single 
instruction single data) 

- ein Befehlsstrom und mehrere Datenströme (SIMD 
= single instruction multiple data) 

—- mehrere Befehlsströme und ein Datenstrom (MISD 
= multiple instruction single data) 

—- mehrere Befehlsströme und mehrere Datenströme 

(MIMD = multiple instruction multiple data). 

Die SISD-Klasse beinhaltet die Monoprozessorsy- 
steme, während es sich bei den anderen drei Klassen 


Architektur-Möglichkeiten und Begriffsbestimmun- 
gen etwas Klarheit zu bringen, werden zunächst 
einige Beispiele zur Klassifizierung solcher 
Systeme angegeben. 


um Multiprozessorsysteme im weitesten Sinne han- 
delt. Bei Systemen mit SIMD- und MSID-Architektu- 
ren handelt es sich um nur wenig verbreitete Spezial- 
rechner, die hier nicht weiter betrachtet werden. 

Systeme der MIMD-Kategorie bestehen allgemein 
aus einer Menge von Systemelementen, die über ein 
Kommunikationssystem miteinander verbunden 
sind. Zur weiteren Klassifizierung der MIMD-Katego- 
rie können folgende Charakteristika herangezogen 
werden |4, 5, 61: 





® Art der Kopplung zwischen den Systemelementen 


(lose, fest) 


Entsprechend der Mächtigkeit der Systeme, die 
miteinander verbunden sind, unterscheidet man 
zwischen lose und fest gekoppelten Systemen. 
Bei lose gekoppelten Systemen bestehen die einzel- 
nen Systemelemente aus kompletten Computern 
(Multicomputersysteme), während in fest gekop- 
pelten Systemen bestimmte Systemelemente wie 
Speicher und Ein-/Ausgabebausteine zur gemein- 
samen Nutzung von mehreren Prozessoren zur Ver- 
fügung stehen (Multiprozessorsysteme). 


@ Entfernung zwischen den Systemelementen 


Bei weit entfernten Systemelementen (Rechnern) 
erfolgt die Kommunikation zwischen den Rechnern 
über Datenfernübertragungseinrichtungen. Hierzu 
gehören die Computernetzwerke. Bei räumlich nah 
angeordneten Mehrrechnersystemen bieten sich 
mehr Kommunikationsmöglichkeiten und sind en- 
gere Verflechtungen in den Problemlösungen mög- 
lich. 


® Art der Funktionszuordnung (statisch, dynamisch) 


Bei Systemen mit statischer Funktionszuordnung 
besteht eine feste Bindung der einzelnen Funktio- 
nen zu den einzelnen Rechnern, d.h. jeder ist für 
die Abarbeitung ganz bestimmter Funktionen zu- 
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ständig. Die Funktionsverteilung wird bei der Sy- 
stemimplementierung festgelegt. 
Bei Systemen mit dynamischer Funktionszuord- 
nung können die einzelnen Funktionen von mehre- 
ren oder allen Rechnern ausgeführt werden. Die 
Auswahl eines geeigneten Rechners, d.h. die 
Zuordnung Funktion — Rechner erfolgt dynamisch 
durch das Betriebssystem. Einige Systeme benutzen 
in Abhängigkeit vom Funktionstyp eine Mischung 
aus statischer u. dynamischer Funktionszuord- 
nung. 

® Priorität der Rechner untereinander (hierarchisch, 
gleichberechtigt) 
Bei hierarchisch aufgebauten Systemen werden die 
Rechner niedriger Priorität von denen höherer Prio- 
rität gesteuert. Hierzu gehören die Master-Slave-Sy- 
steme (2stufige Hierarchie). Die Priorisierung der 
Rechner kann durch die Architektur vorgegeben 
sein oder per Software vorgenommen werden. Bei 
gleichberechtigten Systemen gibt es keine ausge- 
zeichneten Rechner, d. h. alle Rechner sind mit den 
gleichen Möglichkeiten ausgestattet. 


® Architektur des Kommunikationssystems 
Das Kommunikationssystem verbindet die einzel- 
nen Systemelemente miteinander und ermöglicht 
den Datenaustausch zwischen den einzelnen Rech- 
nern. Hierbei kann man zwischen Systemen mit kol- 
lektiven Kommunikationswegen (Bus-Systeme) 
und Systemen mit individuellen Kommunika- 
tionswegen (Ring, Maschennetz, Baum) unter- 
scheiden. In Abschnitt 3 wird dieser Punkt näher 
behandelt. 

© Art des Datenaustausches 
Der Datenaustausch zwischen den Rechnern kann 
grundsätzlich seriell oder parallel erfolgen. Die 
Wahl der Übertragungsart ist abhängig von den Ge- 
schwindigkeitsanforderungen und dem Verdrah- 
tungsaufwand. Im nächsten Abschnitt werden ver- 
schiedene Möglichkeiten zur Implementierung ei- 
nes parallelen Datenaustausches aufgezeigt. Auf se- 
rielle Übertragungsmechanismen wird nicht näher 
eingegangen. 
In den nachfolgenden Ausführungen wird immer 

wieder Bezug genommen auf das im 1. Teil vorge- 

stellte Multi-Mikrocomputersystem (Bild 1), den so- 


F = Funktionsrechner 


Bild 1. Struktur des Arbeitsplatzcompu- 
ters 


= Dialogrechner 
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genannten Arbeitsplatzcomputer |7|. Dabei wird zwi- 

schen zwei Rechnertypen unterschieden: 

— Dialogrechner 
An jeden Dialogrechner ist eine Konsole ange- 
schlossen. Damit besteht eine eindeutige Zuord- 
nung zwischen Benutzer und Dialogrechner, d.h. 
Dialogrechner arbeiten benutzerorientiert. 

— Funktionsrechner 
Auf den Funktionsrechnern sind bestimmte Funk- 
tionen implementiert, die von jedem Dialogrechner 
in Anspruch genommen werden können,d. h. Funk- 
tionsrechner arbeiten funktionsorientiert. 

Weitere Merkmale des Arbeitsplatzcomputers sind: 

— lose gekoppeltes System mit autonomen Rechnern 

- räumlich nah angeordnete Rechner 

—je nach Funktionstyp statische oder dynamische 
Funktionszuordnung 

— gleiche Priorität bei Rechnern gleichen Typs 

— ein Bus-System für die Kommunikation 

— paralleler Datenaustausch. 


2 Datenaustausch-Verfahren 


Die Verfahren für den parallelen Datenaustausch 
zwischen autonomen Rechnern eines Mehrrechnersy- 
stems lassen sich in zwei Klassen einteilen: 

— Softwaregesteuerter Datenaustausch 

Dabei wird der Datenaustausch per Software durch- 

geführt, evtl. unter Zuhilfenahme von Hardware- 

Hilfsmitteln. 

— Hardwaregesteuerter Datenaustausch 

Dabei wird der Datenaustausch per Hardware ohne 

Beteiligung von Software durchgeführt. 

Die nachfolgend angegebenen drei Verfahren sind 
typische Vertreter der softwaregesteuerten Datenaus- 
tausch-Mechanismen. Sie arbeiten jeweils nach dem 
Handshaking-Prinzip 8. 


© Datenaustausch mit Software-Synchronisierung 


Hierbei erfolgt der Datenaustausch rein programm- 
gesteuert ohne Zuhilfenahme von Hardware. Der 
Datenaustausch zwischen den Rechnern wird per 
Software über Ein-/Ausgabeports vorgenommen. 
Die zur Synchronisierung von Sender und Empfän- 
ger erforderlichen Steuersignale werden bei diesem 
Verfahren ebenfalls softwaremäßig generiert und 
über Ports einander zugesendet. Die hiermit erziel- 
baren Übertragungsgeschwindigkeiten sind relativ 
klein. 


® Datenaustausch mit Hardware-Synchronisation 


Wie zuvor erfolgt der Datenaustausch zwischen-den 
Rechnern per Software über Ein-/Ausgabeports, die 
zur Synchronisation von Sender und Empfänger er- 
forderlichen Steuersignale werden jedoch hard- 
waremäßig generiert. Damit reduziert sich der 
Software-Anteil an der Übertragungsprozedur (in- 
terruptgesteuert) und erhöht sich die Übertragungs- 
rate. 


® Datenaustausch über direkten Speicherzugriff 


Hierbei wird der Datenaustausch nicht über Ein-/ 
Ausgabeports, sondern über Software-Zugriffe auf 


den Speicher von Sende- und Empfangsrechner 
vorgenommen. Eine Hardwaresteuerung gestattet 
beispielsweise dem Senderechner, während des Da- 
tentransfers Schreiboperationen auf dem Speicher 
des Empfangsrechners durchzuführen. Damit ist für 
den Datenaustausch nur noch in einem Rechner 
Software erforderlich. Das ermöglicht die höchste 
Übertragungsrate unter den softwaregesteuerten 
Übertragungsmethoden. 


Bei Datenaustausch-Verfahren kann grundsätzlich 
die Übertragungsgeschwindigkeit gesteigert werden, 
wenn für die Realisierung der Übertragungsprozedu- 
ren der Software-Anteil reduziert und entsprechende 
Hardware eingesetzt wird. 


Beim hardwaregesteuerten Datenaustausch läuft 
* der Datentransfer ohne CPU-Beteiligung, d.h. ohne 
jegliche Software ab. Damit hängt die Übertragungs- 
rate auch nicht mehr von der Arbeitsgeschwindigkeit 
der Rechner ab. Ein typisches Verfahren dieser Klasse 
ist der hardwaregesteuerte direkte Speicherzugriff 
(DMA = direct memory access). 


Die DMA-Steuerung verschafft sich für die Daten- 
übertragung Zugriff auf die Speicherbereiche von 
Sende- und Empfangsrechner und steuert, ebenfalls 
im Handshaking-Prinzip, den Datenaustausch. Die er- 
reichbare Übertragungsgeschwindigkeit hängt von 
der Arbeitsgeschwindigkeit der DMA-Steuerung und 
den Speicherzugriffszeiten ab und liegt in der Regel 
um Größenordnungen höher als beim softwaregesteu- 
erten Datenaustausch. 


3 Architektur von Mehrrechnersystemen 
3.1 Kommunikationssystem 


Die Wahl des Datenaustausch-Verfahrens ist relativ 
unabhängig von dem darauf aufbauenden Kommuni- 
kationssystem, das die einzelnen Rechner miteinan- 
der verbindet und maßgebend die Architektur des 
Mehrrechnersystems bestimmt. Beim Entwurf des 
Kommunikationssystems sind prinzipiell folgende 
Zielsetzungen anzustreben: 


- flexibler Aufbau 

— gute Erweiterbarkeit 

— optimale Leistung 

— hohe Verfügbarkeit 

— gute Betriebssicherheit 
— hoher Durchsatz. 


Diese grundsätzlichen Zielvorstellungen sind ent- 
sprechend der vorgesehenen Einsatzgebiete zu ge- 
wichten und mit den technischen und ökonomischen 
Randbedingungen abzustimmen. 


Anhand der Art der Kommunikationswege (Ver- 
bindungsleitungen zwischen den Rechnern) kann 
eine weitere Klassifizierung von Mehrrechnersyste- 
men vorgenommen werden |9): 


— Systeme mit individuellen Kommunikationswegen 
Hierbei sind die einzelnen Rechner über fest zuge- 
ordnete Verbindungsleitungen miteinander gekop- 
pelt. Zu dieser Klasse gehören Ring-, Maschennetz-, 
und Baumstrukturen. Beispiele hierfürsindinBild2 
dargestellt. 





Bild 2. Beispiele für Mehrrechnerstrukturen mit individuellen Kom- 
munikationswegen, a) Ring, b) Maschennetz, c) Baum 














Bild 4. Beispiele für Mehrrechnerstrukturen mit individuellen und 
kollektiven Kommunikationswegen 





Bild 3. » 

Beispiele für Mehrrechnerstrukturen mit kollektiven Kommunika- 
tionswegen, a) Arbeitsplatzcomputer mit Uni-Bus. b) Arbeitsplatz- 
computer mit Zweifach-Bus, c) Arbeitsplatzcomputer mit Kreuz- 
schienenverteiler 
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—- Systeme mit kollektiven Kommunikationswegen 


Hierbei erfolgt die Koppelung der Rechner über ge- 
meinsam benutzte Verbindungsleitungen. Zu dieser 
Klasse gehören die Bus-Systeme, auf die nachfol- 
gend näher eingegangen wird. BeispielesindinBild 
3 angegeben. 


— Systeme mit kollektiven und individuellen Kom- 
munikationswegen 


Bei komplexen Mehrrechnersystemen findet man 
auch oftmals Mischungen aus den ersten beiden 
Struktur-Klassen. Beispiele finden sich in Bild 4. 


3.2 Bus-Systeme 


Die meisten Mehrrechnerstrukturen verwenden 
Bus-Systeme. Entsprechend der unterschiedlichen 
Anforderungen ergeben sich Bus-Systeme unter- 
schiedlicher Leistungsfähigkeit und Komplexität. 
Drei typische Vertreter dieser Klasse sind 10): 


— Uni-Bus-Systeme 


Hierbei erfolgt die gesamte Kommunikation zwi- 
schen den Rechnern über eine gemeinsame Sam- 
melschiene. Damit kann mit relativ geringem Auf- 
wand eine hohe Modularität und Flexibilität er- 
reicht werden. Allerdings kann bei System-Erweite- 
rungen der Bus zum Engpaß werden. Außerdem 
kommt das Auftreten eines Defekts in der Bus-Steue- 
rung einem totalen System-Ausfall gleich. Bild 3a 
zeigt den Aufbau des Arbeitsplatzcomputers mit 
Uni-Bus als Kommunikationssystem. 


— Multi-Bus-Systeme (Bild 3b) 


Hierbei stehen für die Rechner-Rechner-Kommuni- 
kation mehrere Sammelschienen zur Verfügung. 
Damit erhöht sich die Sicherheit und Verfügbarkeit 
des Systems, allerdings auf Kosten eines höheren 
Aufwands, da außer der Mehrfach-Auslegung des 
Busses eine Steuerlogik für die Auswahl und Über- 
wachung erforderlich ist. In Bild 3b ist der Aufbau 
des Arbeitsplatzcomputers mit Zweifach-Bus als 
Kommunikationssystem dargestellt. 


Datei - 
Rechner 


DFÜ- 
Rechner 


Funktions- 
rechner 


Peripherie- 
Rechner 


Uni-Bus 





Dialog - 
Rechner 


Bild 5. Arbeitsplatzcomputer als Ein-Benutzer-System mit 
Uni-Bus 
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— Systeme mit Kreuzschienenverteiler (Crossbar) 


Hierbei sind m Systemelemente eines Typs (z.B. 
Dialogrechner) mit n Systemelementen eines ande- 
ren Typs (z. B. Funktionsrechner) matrixartig mit- 
einander verbunden. Damit können bis zumin (m, n) 
Transfers gleichzeitig erfolgen. Jeder der m x n- 
Kreuzungspunkte beinhaltet eine Schalterfunktion 
und eine Auswahl-Logik, um bei Mehrfach-Anfor- 
derungen Bus-Konflikte zu verhindern. Dies macht 
einen erheblichen Aufwand erforderlich. Bild 3c 
zeigt den Aufbau des Arbeitsplatzcomputers als Sy- 
stem mit Kreuzschienenverteiler. 


4 Implementierung einer Uni-Bus-Struktur für 
den Arbeitsplatzcomputer 


In den nachfolgenden Ausführungen wird ein Lö- 
sungsvorschlag zur Implementierung eines Uni-Bus- 
Systems vorgestellt. Als Beispiel dient der Arbeits- 
platzcomputer in Form eines Einzelplatzsystems 
(single user system) mit dem in Bild 5 dargestellten 
Aufbau. Um bei der Rechner-Rechner-Kommunika- 
tion möglichst hohe Übertragungsraten erzielen zu 
können, wird als Datenaustausch-Verfahren der 
hardwaregesteuerte direkte Speicherzugriff gewählt. 


Der Kern des Kommunikationssystems ist der pro- 
grammierbare DMA-Controller. Die Programmierung 
des DMA-Steuerbausteins, bei der diesem wichtige In- 
formationen für den Datenaustausch (z. B. Blockan- 
fangsadresse, Blocklänge, Übertragungsrichtung) 
mitgeteilt werden, obliegt nur dem Dialogrechner. Er 
kann auf Wunsch mit jedem der Funktionsrechner, die 
völlig gleichberechtigt sind, Daten austauschen. Da- 
mit die Adreßbereiche für den Datenaustausch in 
Sende- und Empfangsrechner voneinander unabhän- 
gig sind, ist für jeden Funktionsrechner eine Adreß- 
geberlogik vorgesehen, die vom Funktionsrechner 
programmiert werden kann. 


In Bild 6a ist der Zustand des DMA-Busses für eine 
Datenübertragung vom Dialogrechner (DR) zu Funk- 
tionsrechner 1 (FR1) dargestellt. Dabei wird der Steu- 
erbus von Sender und Empfänger vom DMA-Control- 
ler mit den für die Speicherzugriffe erforderlichen Si- 
gnalen versorgt. Die Adreßbusse von Sender und 
Empfänger sind nicht miteinander verbunden, damit 
Daten aus einem beliebigen Quellbereich in einen be- 
liebigen Zielbereich transferiert werden können. Für 
den Transfer müssen die beiden Datenbusse mitein- 
ander verbunden und in der entsprechenden Richtung 
durchgeschaltet sein. 


Eingeleitet wird der Datenaustausch durch folgenden, 
Mechanismus (Bild 6b): Für den Verbindungsaufbau 
erfolgt zunächst die Programmierung des DMA-Con- 
trollers und die Prüfung, ob FR 1 verfügbar ist. Falls ja, 
wird vom DR der Systembus von FR 1 angefordert ®. 
Sobald der DMA-Bus über den Systembus von FR 1 
verfügen kann ® , fordert der DMA-Controller den 
Systembus von DRan ® .Nach Quittungsempfang ® 
kann mit der Kommunikationsphase begonnen wer- 
den. 





Steuerbus 


Steuerbus 





Adrenbus 


Adrefbus 
Datenbus 


Datenbus 
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Bild 6. Datenaustausch beim Arbeitsplatzcomputer über DMA-Bus 
am Beispiel einer Übertragung vom Dialogrechner zum Funktions- 
rechner 1, a) Kommunikationsphase, b) Initialisierungsphase 


Die Kommunikationsphase läuft in folgenden 
Schritten ab: 


Zunächst wird vom DMA-Controller die Anfangs- 
adresse des zu übertragenden Datenblocks auf den 
Adreßbus vom DR gelegt und ein Speicherlesesignal 
generiert. Damit gelangt das erste Datum auf den Da- 
tenbus von DR und FR 1. Außerdem wird von dem zu 
FR 1 gehörenden Adreßgeber die Zieladresse auf den 
Adreßbus von FR 1 gelegt. Nun wird vom DMA-Con- 
troller ein Speicherschreibsignal erzeugt und an FR 1 
gesendet, womit dieam Datenbus anliegende Informa- 
tion in der adressierten Speicherzelle angelegt wird. 
Danach wird Quell- und Zieladresse inkrementiert 
und das nächste Datum übertragen. Dieser Vorgang 
wiederholt sich solange, bis der gesamte Datenblock 
übertragen ist. 


Der Datenaustausch wird abgeschlossen durch den 
Verbindungsabbau und die Generierung eines Unter- 
brechungssignals für FR 1, womit ihm der Empfang 
des Datenblocks gemeldet wird. 


Ein Nachteil dieser Bus-Struktur liegt darin, daß die 
Programmierung des DMA-Controllers nur vom Dia- 
logrechner aus vorgenommen werden kann und da- 
durch eine Master-Slave-Struktur entsteht. Zur Besei- 
tigung dieses Nachteils kann der Bus-Steuerung ein 
eigener Rechner (Bus-Rechner) zugeordnet werden, 
dessen Aufgabe darin besteht, Kommunikationsan- 
forderungen zu erkennen und zu behandeln. Die Exi- 
stenz eines Bus-Rechners kann z.B. auch verwendet 
werden, um bei der Auftragsvergabe in Abhängigkeit 

















vom Auftragstyp einen geeigneten Funktionsrechner 
zu ermitteln oder einen bestimmten Funktionsrechner 
auf dessen Bereitschaft zur Auftragsannahme zu prü- 
fen oder bestimmte Maßnahmen zur Fehlererkennung 
und -behandlung vorzunehmen. Außerdem kann er 
für gewisse organisatorische Aufgaben herangezogen 
werden, beispielsweise zur Verhinderung von Ver- 
klemmunsgssituationen. Es ist jedoch wichtig, darauf 
zu achten, daß der Charakter eines völlig dezentral ar- 
beitenden Mehrrechnersystems erhalten bleibt. 
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3. Teil: Verteiltes Betriebssystem eines Mehrrechnersystems 


Für ein interaktives Mehrrechnersystem wird ein 
verteiltes Betriebssystem beschrieben, das an die 
jeweilige Einsatzanforderung angepaßt werden 
kann. Es ist sowohl ein Ein-Benutzer-, wie auch ein 
Mehr-Benutzer-System mit beliebig vielen Hinter- 
grundrechnern möglich, wobei die anfallenden Auf- 
träge parallel bearbeitet werden. 


Die Hardware besteht aus einer beliebigen Anzahl 
von Rechnermodulen, die über ein Bussystem gekop- 
pelt sind. Diese werden nach ihrem Aufgabenspek- 
trum unterteilt in Dialog- und Funktionsrechner. Die 
Dialogrechner überwachen die Ausführung der An- 
wenderprogramme und steuern den Dialog mit den 
Anwendern über angeschlossene Bildschirmeinhei- 
ten. Außerdem verteilen sie Aufträge an die Funk- 
tionsrechner, die diese dann in eigener Regie ausfüh- 
ren. 

Bei der Struktur und den Hauptmerkmalen des Be- 
triebssystems steht die Forderung nach Modularität 
und Anpassung an flexible Hardware im Vorder- 
grund. Dies wird vor allem erreicht durch die Bereit- 
stellung von Betriebssystem-Bausteinen und eine Li- 
stenstruktur, die die aktuelle Systemkonfiguration re- 
präsentiert. 


1 Hardwarestruktur 


Den Hardwareaufbau des Systems zeigt Bild 1. 
Sämtliche Rechner sind über ein Bussystem verbun- 
den. Dabei verfügt jede Einheit über eine Verarbei- 
tungseinheit (CPU) und einen eigenen Speicher 
(RAM) zur Aufnahme von Daten und Programmen, 
um die selbständige Bearbeitung von Funktionen zu 
gewährleisten. Die Zahl der anschließbaren Rechner 
ist variabel. 

Die Dialogrechner (DR) stellen die Schnittstelle 
zwischen Benutzer und dem System dar. Sie haben die 
Aufgabe, Kommandos vom Benutzer zu interpretieren 
und auszuführen, Anwenderprogramme zu laden und 
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deren Ausführung zu überwachen. Dabei ist jeder DR 
nur für das Programm eines Benutzers zuständig. Das 
heißt, diese Rechner arbeiten benutzerorientiert. Die 
hierbei anfallende Überwachungsfunktion beinhaltet 
vor allem die Verteilung von Systemfunktionen an die 
Funktionsrechner und deren Koordinierung. 

Im Gegensatz zu den Dialogrechnern arbeiten die 
Funktionsrechner (FR) funktionsorientiert, d.h. sie 
erledigen für beliebige Auftraggeber innerhalb des 
Systems bestimmte Arbeiten. Diese Aufgaben können 
sowohl das Vorhandensein bestimmter, an diese 
Rechner angeschlossener Peripheriegeräte vorausset- 
zen, als auch reine Verarbeitungsfunktionen beinhal- 
ten. Die Bearbeitung dieser Aufträge erfolgt selbstän- 
dig, solange die benötigten Betriebsmittel direkt ver- 
fügbar sind. Anderenfalls können Aufträge an andere 
Funktionsrechner delegiert werden. 


Pheripherie 


Interne 
Kommunikatıon 


Diologrechner 


Benutzer 


Bild 1. Struktur des Mehrrechnersystems 


Funktionsrechner 


Über ein internes Bussystem kommunizieren die 
Rechnereinheiten untereinander. Dort werden Auf- 
träge, Daten und Zustandsmeldungen übertragen. Der 
Datenaustausch wird über Direct Memory Access 
(DMA) vorgenommen (siehe Teil 2). Dabei handelt es 
sich um eine sehr schnelle parallele, rein hardware- 
gesteuerte Datenübertragung. 

Der Datenaustausch zwischen den Rechnern wird 
über Meldungen abgewickelt. Der Empfänger wird zur 
Übernahme der Meldung in seinen laufenden Arbei- 
ten unterbrochen. Das ermöglicht trotz selbständiger 
Arbeitsweise der Einzelrechner beliebige Kommuni- 
kationen zu beliebigen Zeitpunkten. 


2 Merkmale des Betriebssystems 


Das Betriebssystem (BS) ist für unterschiedliche 

"Konfigurationen und Leistungsanforderungen konzi- 
.piert. Es soll sowohl Ein- als auch Mehrbenutzerbe- 
trieb ermöglichen und eine beliebige Zahl von Funk- 
tionsrechnern und Peripheriegeräten zulassen. Hierzu 
wird aus BS-Modulen ein individuelles Betriebssy- 
stem erstellt, das den jeweiligen Gegebenheiten ange- 
paßt ist. 

Die Flexibilität des Systems wird erreicht durch 
strenge Strukturierung und die Definition klarer 
Schnittstellen zwischen den einzelnen Betriebssy- 
stem-Bausteinen. Die Verteilung der Aufträge auf die 
einzelnen Rechner erfolgt ausschließlich über Sy- 
stemlisten. Diese werden bei der Generierung des 
Systems erstellt und repräsentieren die aktuelle 
Konfiguration. Sie enthalten Angaben über ange- 
schlossene Rechner, deren Peripheriegeräte und das 
Spektrum der von jedem Rechner ausführbaren Funk- 
tionen. 

Parallelarbeit im System wird realisiert zum einen 
durch Einführung eines Mehrbenutzerbetriebs mit 
mehreren Dialogrechnern und zum anderen durch die 
Parallelisierung von Teilaufgaben der Anwenderpro- 
gramme. 

Die Parallelisierung innerhalb einzelner Anwen- 
derprogramme erfolgt durch die Delegierung von Auf- 
trägen an die Funktionsrechner in Form von System- 
aufrufen. Dabei wird zwischen Basis-Systemdiensten 
und Anwender-Systemdiensten unterschieden. 

Unter einem Basis-Systemdienst (BSD) wird eine 
Betriebssystemfunktion verstanden, die zur Bedie- 
nung von Peripheriegeräten, Dateiverwaltung oder 
Ablaufsteuerung dient. Wesentlich ist, daß diese Sy- 
stemdienste von einem Rechner ohne die Hilfe ande- 
rer erledigt werden können. Die dazu benötigten Sy- 
stemroutinen sind resident gespeichert. BSDs sind 
z.B. Eingabe- und Ausgabeaufträge, Öffnen und 
Schließen von Dateien sowie Warten auf Rückmel- 
dungen von Aufträgen. Beim Erkennen solcher Sy- 
stemaufrufe wird analysiert, ob der entsprechende 
Rechner die gewünschte Funktion selbst ausführen 
kann, oder ob dieser Auftrag an einen anderen Rech- 
ner delegiert werden muß. 

Anwender-Systemdienste (ASD) können vom An- 
wender, unterstützt vom Betriebssystem, selbst defi- 
niert werden. Sie haben den Zweck, bestimmte Funk- 
tionen eines Anwenderprogramms auf beliebige 


Funktionsrechner auszulagern, die diese parallel zu 
anderen Programmteilen ausführen. Im Unterschied 
zum BSD kann ein ASD von jedem beliebigen Rechner 
bearbeitet werden. Ein weiteres Merkmal der ASDs 
besteht darin, daß sie nicht zum residenten Teil des 
Betriebssystems gehören. Die ASD-Routinen werden 
vielmehr bei Bedarf von einem externen Speicher ge- 
laden, um Speicherplatz in den Funktionsrechnern 
einzusparen. 

Beispiele solcher ASDs sind das Durchsuchen von 
Dateien, Formatierung von Daten oder die Abwick- 
lung eines Datenaustausches mit einem Großrechner. 


3 Arbeitsweise des Systems 


Jeder Dialogrechner übernimmt die Ausführung ei- 
nes Anwenderprogramms einschließlich Benutzer- 
dialog und delegiert gegebenenfalls die im Programm 
aufgerufenen Systemdienste an die Funktionsrechner. 
Basis-Systemdienste, die Peripheriegeräte anspre- 
chen, werden ausschließlich an Funktionsrechner de- 
legiert, die diese Geräte steuern, während Anwen- 
der-Systemdienste nach vorgegebenen Strategien 
(z. B. erster freier FR, der am wenigsten ausgelastete 
FR) vergeben werden. 

Um nach der Auftragsvergabe die Programmbear- 
beitung fortsetzen zu können, wird ein delegierter 
Auftrag in einer Tabelle festgehalten. Dadurch werden 
zeitliche Überwachung, spätere Synchronisierung 
und richtige Zuordnung von eventuell eintreffenden 
Rückmeldungen des betreffenden Auftrags ermög- 
licht. Die Aufnahme in die Tabelle ist allerdings nur 
dann notwendig, wenn von einem Auftrag Ergebnisse 
zurückerwartet werden und bis zum Eintreffen dieser 
Ergebnisse andere Arbeiten zu erledigen sind. Ande- 
renfalls gibt der Auftraggeber die Verantwortung an 
den ausführenden Funktionsrechner ab und setzt 
seine Arbeiten ohne weitere Bezugnahme auf den de- 
legierten Auftrag fort. Eine Rückmeldung erfolgt le- 
diglich im Fehlerfall. 

Ein FR kann zwei Typen von Aufträgen bearbeiten: 
Anwender-Systemdienste und Basis-Systemdienste. 
Artund Umfang der ausführbaren BSDs werden durch 
die angeschlossene Peripherie bestimmt, während 
hinsichtlich der ASDs keine Einschränkungen beste- 
hen. Da alle Rechner selbständig arbeiten und Auf- 
träge zu beliebigen Zeitpunkten eintreffen können, ist 
es erforderlich, die eingehenden Aufträge in einer 
Warteschlange zwischenzuspeichern, um beim Auf- 
traggeber keine unnötigen Wartezeiten entstehen zu 
lassen. 

Die in die Warteschlange aufgenommenen Aufträge 
werden entweder nach der Reihenfolge ihres Eintref- 
fens (first in - first out), oder nach Dringlichkeit (Prio- 
rität) abgearbeitet. 

In Bild 2 wird die Arbeitsweise des Systems anhand 
eines schematisierten Ablaufs eines Benutzerpro- 
gramms veranschaulicht. Als Hardwarekonfiguration 
wird z.B. ein System mit einem Dialogrechner und 
zwei Funktionsrechnern vorausgesetzt. Dabei werden 
nur die für das Zusammenspiel der einzelnen Rechner 
wichtigen Programmteile markiert. Zur Identifizie- 
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rung werden die einzelnen Aufträge fortlaufend 
durchnumeriert. 


4 Struktur des Betriebssystems 


Das gesamte Betriebssystem ist so strukturiert, daß 
jedem Rechner jeweils nur die Funktionen zugeordnet 
werden, die seinem Aufgabenspektrum entsprechen 
(Bild 3). 

Das Basis-BS enthält Routinen, die auf allen Rech- 
nern verfügbar sein müssen. Dazu gehören Auftrags- 
verwaltung, Kommunikationssteuerung sowie Ana- 
lyse und Verteilung von Systemdiensten. 

Spezifisch für die Dialogrechner sind die Routinen 
zur Interpretation und Ausführung von Benutzer- 
kommandos, wozu auch das Laden und die Ausfüh- 
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Benutzerprogramm 
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rungsüberwachung von Anwender- und Dienstpro- 
grammen gehört. Kommandos und Eingaben können 
auch im Stapelbetrieb verarbeitet werden. Außerdem 
müssen diese Rechner die Behandlung von System- 
Fehlermeldungen vorsehen. 


Die Funktionsrechner enthalten Routinen zur Auf- 
tragsannahme, Einrichtung und Bearbeitung von War- 
teschlangen, Speicherverwaltung, Ausführung von 
Basis-Systemdiensten, Laden und Ausführung von 
Anwender-Systemdiensten sowie die Steuerung der 
jeweils angeschlossenen Peripheriegeräte. 


Die oben beschriebenen Betriebssystem-Teile wer- 
den bei der Systeminitialisierung geladen und bilden 
das statische (residente) Betriebssystem der jeweili- 
gen Rechner. Die Anwender-Systemdienste dagegen 
können bei Bedarf von jedem Rechner geladen werden 
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Rechner FR1 Rechner FR2 
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Bild 3. Bausteine des Betriebssystems 





und gehören somit zum dynamischen (nicht residen- 
ten) Teil des Betriebssystems. 


5 Systemgenerierung 


Unter Systemgenerierung wird das Zusammenstel- 
len der aktuellen Betriebssystem-Software für eine 
spezielle Rechnerkonfiguration verstanden. Bei der 
Systeminbetriebnahme wird die Zahl der Dialogrech- 
ner und Funktionsrechner sowie die Zuordnung von 
Peripheriegeräten zu diesen Rechnern angegeben. 
Aus diesen Angaben werden die entsprechenden Be- 
triebssystem-Moduln (s. Bild 3) für die einzelnen 
Komponenten zusammengestellt und die Systemli- 
sten aufgebaut, die diese Konfiguration wiedergeben. 
Bei der Systeminitialisierung lädt jeder Rechner diese 
Listen und die für ihn relevanten Teile des Betriebssy- 
stems. 

Aufgrund der listenorientierten Arbeitsweise des 
Systems kann auch im Betrieb eine Umkonfigurierung 
vorgenommen werden. Dies ist z. B. nach dem Erken- 
nen von fehlerhaften Komponenten sinnvoll. Durch 
Änderung der Listen werden fehlerhafte Rechner 
stillgelegt und deren Funktionen anderen Einheiten 
übertragen. Die nicht beendeten Aufträge werden von 
den jeweiligen Auftraggebern neu vergeben. 


6 Betriebssystem-Schniittstelle zum Anwender 


Das Betriebssystem bietet dem Anwender Hilfen, 
die ihm ein einfaches Arbeiten mit einem solchen 
Mehrrechnersystem ermöglichen. Eine wichtige For- 


derung dafür ist, daß der Benutzer keine Rücksicht auf 
die aktuelle Hardwarekonfiguration nehmen muß. 
Das giltsowohl für die Kommandospracheals auch für 
die Programmierung. Weiterhin müssen Software- 
Testhilfen, wie Monitor, Tracer u.ä. zur Verfügung 
stehen, die insbesondere auch das Zusammenspiel der 
einzelnen Rechner berücksichtigen. 

Die Programmierung paralleler Prozesse wird er- 
leichtert durch einfache Unterprogrammaufrufe (Sy- 
stemdienstaufrufe). Für einige Parameter können ge- 
gebenenfalls die vom System vorgegebenen Standards 
eingesetzt werden. Dies ermöglicht dem Programmie- 
rer ein stufenweises Einarbeiten in die Möglichkeiten 
des Systems. 

Schließlich kann der Benutzer Teilroutinen oder 
Unterprogramme definieren, die das Betriebssystem 
als Anwender-Systemdienste übernimmt. Damit kann 
er sich selbst die Hilfsmittel zur Parallelisierung sei- 
nes Problems schaffen. 
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Dr.-Ing. Gerd Sandweg, Dipl.-Ing. Frank Schmidtke 
Ein Multi-Mikrocomputer-System 


am Arbeitsplatz 


4. Teil: Praktische Einsatzbeispiele eines 
Multi-Mikrocomputer-Systems 


Ein Mehrrechnersystem kann aufgrund seiner Fle- 
xibilität einen großen Aufgabenbereich abdecken, 
der von Minicomputeraufgaben bis zu Großrech- 
nersystemleistungen reicht. Dieses Einsatzspek- 
trum soll hier skizziert werden. Außerdem sind drei 
Programmbeispiele beschrieben, die die Dialogfüh- 
rung, Datenfernverarbeitung und ein Datenbank- 
system betreffen. 


In den vorausgegangenen Aufsätzen dieser Reihe 
wurden Konzept und Zielsetzung eines Multi-Mikro- 
computer-Systems vorgestellt. Nun werden Einsatz- 
möglichkeiten eines solchen Systems skizziert und 
drei Anwenderprogrammpakete beschrieben. Sie be- 
treffen die Dialogführung, Datenfernverarbeitung und 
ein Datenbanksystem. Die Programme wurden in er- 
ster Linie als Test- und Demonstrationsbeispiele ent- 
wickelt und sollten nicht mit kommerziellen Pro- 
grammsystemen verglichen werden. Die vorgestellten 
Programmpakete wurden auf einem Mehrrechnersy- 
stem mit vier Mikrocomputern erstellt und ausgete- 
stet. 


1 Einsatzspektrum 


Ein Ziel eines Multi-Mikrocomputer-Systems liegt 
darin, durch Parallelarbeit von standardisierten, billi- 
gen Hardwarekomponenten ein besseres Preis/Lei- 
stungsverhältnis als bei einem hochgezüchteten Ein- 
zelrechner zu ermöglichen. Dieses Ziel ist nur dann 
erreichbar, wenn die zu bearbeitenden Aufgaben groß 
genug und parallelisierbar sind, um mehrere Rechner 
auslasten zu können. Bei einem Mehrrechnersystem 
ist eine Parallelarbeit auf Task- und auf Jobebene sinn- 
voll. 

Unter Parallelarbeit auf Taskebene wird hier die 
gleichzeitige Abarbeitung von abgeschlossenen Teil- 
aufgaben eines Programms auf mehreren Rechnern 
verstanden. Solche Teilaufgaben können z. B. die Be- 
dienung von Peripheriegeräten oder Dateioperationen 
sein. Der Entwickler von Anwendersoftware sollte 
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eine gegebene Aufgabe in möglichst parallel bearbeit- 
bare Teile zerlegen. Dies ist schwierig, wenn sequen- 
tielle Abhängigkeiten bestehen (z. B. Compiler, Edi- 
tor). Einfach ist dagegen die Aufteilung, wenn ein 
Programm aus funktionellen Blöcken besteht, die nur 
schwach verkoppelt sind, oder wenn große Daten- 
mengen zu verarbeiten sind, die sich in Teilfelder 
gliedern lassen (z. B. Suchen, Sortieren, Bildverarbei- 
tung, bestimmte Matrixoperationen). Eine weitere 
Maßnahme zur Steigerung der Effektivität eines 
Mehrrechnersystems ist die Realisierung der Parallel- 
arbeit auf Jobebene. Dabei werden gleichzeitig An- 
wenderprogramme mehrerer Benutzer bearbeitet. 

Unter Berücksichtigung der obrigen Überlegungen 
lassen sich folgende Rechnerkonfigurationen, An- 
wendungsbeispiele und Einsatzgebiete angeben: 

Minimalkonfiguration mit zwei Rechnern: 

Kleine Anwendungen, für die heute Minicomputer. 
eingesetzt werden; Aufteilung in Hauptrechner und 
Ein-/Ausgaberechner bietet sich an. 

Einbenutzersystem mit bis zu vier Rechnern: 

Informationssystem, intelligentes Terminal, Auf- 
tragsverfolgung, Lagerverwaltung, Buchhaltung, 
Textverarbeitung; Einsatz in Sekretariat, Arztpraxis, 
Ingenieurbüro usw. 

Mehrbenutzersystem mit vielen Rechnern: . 

Datenbanken, Verwaltung, technisch-wissenschaft- 
liche Berechnungen; Einsatz in Büro, Klinik, Univer- 
sität usw. 


2 Dialoghilfen für Anwenderprogramme 


Ein wichtiger Gesichtspunkt des verwendeten 
Mehrrechnersystems ist die dialogorientierte Ar- 
beitsweise. Die Kommunikation des Benutzers mit ei- 
nem Programm kann auf vier Arten erfolgen: 


a) Strenger Dialog mit Frage und Antwort. 
Der Programmieraufwand hierfür ist gering. Es muß 
immer nur eine Eingabe geprüft und im Fehlerfall 
lediglich die zugehörige Frage wiederholt werden. 


Nachteilig an dieser Dialogart ist der geringe Über- 
blick, der dem Benutzer geboten wird. Bei großen 
Programmen ist es für den Anfänger schwierig, 
durch viele Einzelentscheidungen an die richtige 
Stelle zu gelangen. Andererseits langweilen den 
geübten Benutzer die ausführlichen Fragestellun- 
gen und die vielen notwendigen Eingaben. 


b) Ausfüllen von Masken 


Diese Dialogart setzt ein Bildschirmgerät voraus. 
Auf ihm werden Eingabeformulare, sog. Masken, 
angeboten, deren Felder der Benutzer ausfüllen 
kann. Die Eingaben erfolgen damit parallel in einem 
größeren Zusammenhang und der Benutzer erhält 
einen besseren Überblick über Umgebung, Mög- 
lichkeiten und Auswirkungen einzelner Eingaben. 
Nachteilig bei dieser Dialogart ist der zunächst rela- 
tiv hohe Programmieraufwand. Der Aufbau von 
Masken und die Überprüfung mehrerer gleichzeiti- 
ger Eingaben, die sich eventuell widersprechen 
können, ist aufwendig. Um diese Nachteile zu besei- 
tigen, stehen eine Reihe von Programmbausteinen 
zur Verfügung, die Definition, Ausgabe und Inter- 
pretation von Masken und Maskeneinträgen unter- 
stützen. Ein größerer Baustein dieser Art ist ein sog. 
Maskengenerator. Mit diesem Programm und den 
hardwaremäßigen Editionshilfen eines Bild- 
schirmgeräts kann direkt auf dem Bildschirm eine 
gewünschte Maske erstellt werden. Wenn das Mas- 
kenbild festgelegt ist, können später den einzelnen 
Eintragsfeldern noch Attribute zugeordnet werden, 
die Grenzwerte, Plausibilitätsbedingungen, Forma- 
te, Schutzfunktionen u. ä. betreffen. 


c) Kommandosprache 


Bei den beiden bisher beschriebenen Dialogformen 
liegt die Initiative beim Programm. Dies vereinfacht 
den Dialog auf Kosten der Flexibilität. Will jedoch 
der Benutzer die Initiative übernehmen und soll 
auch die Behandlung von Sonderfällen möglich 
sein, ist eine Kommandosprache das geeignete 
Hilfsmittel. Mit einer geringen Anzahl beliebig 
kombinierbarer Sprachelemente kann dann der ge- 
übte Benutzer alle Möglichkeiten eines Programms 
ausschöpfen. 


Für die Syntaxprüfung und Interpretation solcher 
Kommandos gibt es Programmbausteine, mit deren 
Hilfe der Programmierer schnell eine problemange- 
paßte Kommandosprache definieren kann. 


d)Funktionstastatur 
Mit der Funktionstastatur kann der Benutzer zu be- 
liebigen Zeitpunkten in den Programmablauf ein- 
greifen. Dabei kann die Bedeutung der Funktionsta- 
sten sowohl vom System als auch vom Benutzer- 
programm vorgegeben werden. 


In der Praxis werden die vier genannten Dialogarten 
vermischt angewandt. Bei beiden im folgenden be- 
schriebenen Programmsystemen sind z. B. sowohl 
Maskeneinträge als auch Kommandos möglich. 


3 Datenfernverarbeitung 


Eine wichtige Funktion eines Rechners am Arbeits- 
platz ist der Anschluß an ein Großrechenzentrum. Der 
Benutzer erhält damit Zugang zu zentralen Daten, die 
er vor Ort bearbeiten kann. Dies trägt zu einer Entla- 
stung und effektiveren Ausnutzung von Großrechner 
und Übertragungsleitung bei. Für das beschriebene 
Multi-Mikrocomputer-System stehen Programme zur 
Verfügung, die folgende Funktionen der Datenfern- 
verarbeitung ermöglichen: 


— Automatische Anwahl an ein Rechenzentrum, 
— Anschluß an Großrechenanlage, 

— Senden von Dateien, 

— Empfangen von Dateien, 

— Dialog mit Großrechenanlage, 

— Abbau der Verbindung. 

Zur Einleitung einer Datenfernverarbeitung muß 
der Benutzer zunächst eine Verbindung zu einer 
Großrechenanlage aufbauen. Er kreuzt dazu in einer 
Maske die gewünschte Rechenanlage an, die darauf- 
hin automatisch angewählt wird. Falls keine Verbin- 
dung zustande kommt, können weitere Wählversuche 
unternommen werden. Ist eine Verbindung zum 
Großrechner hergestellt, kann in einer Maske das ge- 
wünschte LOGON-Kommando angekreuzt werden, 
welches an den Großrechner gesendet wird und den 
Anschluß an das Betriebssystem herstellt. Die Masken 
für die Auswahl der Telefonnummern und der LO- 
GON-Kommandos definiert der Benutzer selbst. Än- 
derungen können also ohne Programmieraufwand 
schnell berücksichtigt werden. Für Spezialfälle, die 
durch die gerade verfügbare Maske nicht abgedeckt 
werden, ist ein Eingabefeld vorgesehen, in das der Be- 
nutzer z. B. eine Telefonnummer oder ein besonderes 
LOGON-Kommando eingeben kann. 

Wenn das Betriebssystem der Großrechenanlage 
sich meldet, kann der Benutzer Kommandos an die 
Großrechenanlage schicken und Antworten empfan- 
gen. Das Mehrrechnersystem arbeitet also online als 
Terminal an einer Großrechenanlage. Der Benutzer 
kann aber auch zentral gespeicherte Dateien abrufen, 
sie vor Ort offline bearbeiten und die Ergebnisse wie- 
der zurückschicken. Alle Operationen und Eingaben 
werden soweit möglich bereits vor Ort geprüft. Die 
Programme für die Datenfernverarbeitung dienen also 
dem Komfort und der Sicherheit. Außerdem ist Paral- 
lelarbeit während den Datenübertragungsphasen 
möglich. 


4 Datenbanksystem 


Datenbanksysteme sind für Mehrrechnersysteme 
ein geeignetes Anwendungsbeispiel, da sich typische 
Funktionen wie Suchen und Sortieren relativ leicht 
parallelisieren lassen. Für das hier vorgestellte Mehr- 
rechnersystem wurde ein kleineres Datenbanksystem 
entwickelt, bei dem besonderes Gewicht auf kurze 
Einarbeitungszeit und Benutzerfreundlichkeit gelegt 
wurde. Entsprechend einfach ist die Programmstruk- 
tur. Es gibt nur zwei Ebenen: Auswahlebene und 
Funktionsebene (Bild 1). Die einzelnen Funktionen 
sind durch Programmmodule realisiert, die völlig un- 
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abhängig voneinander sind. Jeder bearbeitet eine Da- 
tei und erzeugt gegebenenfalls eine Ergebnisdatei. 
Diese Ergebnisdatei kann von dem gleichen oder ei- 
nem anderen Modul weiterverarbeitet werden usw. 


Der Dialog des Benutzers mit den Modulen ist ein- 
heitlich und maskenorientiert aufgebaut. Der Anwen- 
der erstellt für jede Datei eine „Dateimaske‘“, die ei- 
nerseits die Struktur der Datensätze definiert und an- 
dererseits für Ein- und Ausgaben von Datenbankfunk- 
tionen dient. 

Will der Benutzer z. B. eine Datei nach bestimmten 
Begriffen durchsuchen, füllt er die Eintragsfelder der 
Dateimaske mit den Zeichenfolgen aus, nach denen in 
den Datensätzen gesucht werden soll (Bild 2). Hierbei 
kann angegeben werden, ob die Zeichenfolge im be- 
treffenden Satzteil enthalten (Normalfall), identisch 
(=), größer (>, bezogen auf alphabetische Ordnung) 
oder kleiner (<) sein soll. Wenn mehrere Felder der 
Dateimaske ausgefüllt werden, wird dies als eine 
UND-Verknüpfung der Bedingungen verstanden. 


Diese Regeln sind sofort einsichtig und erlauben die 
Bearbeitung der häufigsten Fälle. Für Sonderfälle, 
z. B. eine ODER-Verknüpfung, kann unter die Maske 
eine Kommandozeile geschrieben werden. Diese 
Kommandozeile kann in beliebiger Zahl die Feldna- 
men (bzw. Abkürzungen), die Vergleichsfunktionen, 
die Vergleichswerte und die Verknüpfungsoperatoren 
enthalten. Die Eingaben bei den anderen Funktionen 
erfolgen in ähnlicher Weise. 

Für Programmverzweigungen und spezielle funk- 
tionsabhängige Eingaben wird bei jedem Programmo- 
dul eine sog. „Steuermaske“ der Dateimaske vorange- 
stellt. Diese Steuermaske enthält ein Eintragsfeld zur 
Angabe, ob evtl. eine Bedienungsanleitung oder eine 
Beendigung des Moduls gewünscht wird. Außerdem 
enthält die Steuermaske meist zwei Eintragsfelder für 
die Namen der zu bearbeitenden Datei und der Ergeb- 
nisdatei. 


Das bestehende Datenbanksystem eignet sich auf- 
grund seiner Modularität gut für die Realisierung von 
Parallelarbeit in dem beschriebenen Mehrrechnersy- 
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Bild 1. Programmstruktur des Daten- 
banksystems 
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ausdrucken 


stem. So kann bei der Funktion „Suchen“ eine Dateiin 
Teildateien zerlegt werden, die von mehreren Rech- 
nern gleichzeitig durchsucht werden. Bei der Funk- 
tion „Sortieren“ können mehrere Rechner Teildateien 
sortieren und danach ein Rechner die sortierte Ge- 
samtdatei erstellen. Eine andere Art der Parallelarbeit 
ergibt sich bei Funktionen, deren Ende nicht abgewar- 
tet werden muß, wie Ausgaben auf Peripheriegeräte. 
Nach der Delegierung solcher Funktionen können so- 
fort weitere Aufträge bearbeitet werden. Durch Ein- 
führung eines Mehrbenutzerbetriebs läßt sich die 
Auslastung des Mehrrechnersystems noch verbes- 
sern. Hierbei sind allerdings Fragen der Zugriffsbe- 
rechtigung und des Datenschutzes zu beachten. Diese 
Aspekte sind beim Konzept des Datenbanksystems 
von vorneherein berücksichtigt, damit entsprechende 
Erweiterungen schrittweise vorgenommen werden 
können. 
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Bild 2. Beispiel einer ausgefüllten Maske. Der hier 
formulierte Datenbankauftrag lautet: „Suche aus 
der Datei PERSONEN alle Sätze, die im Feld ORT 
das Wort MUENCHEN und im Feld BERUF das 
Wort ANGESTELLTER enthalten. Die gefundenen 
Sätze sollen in der Datei PERSON. 1 abgelegt wer- 
den.“ 
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5. Teil: Entwicklung, Test und Aufbau von Mehrrechnersystemen 


auf Mikrocomputerbasis 


In den vorausgegangenen Teilen dieser Serie wur- 
den generelle und detaillierte Aussagen über Prin- 
zip, Sinn, Ablauf und einige Anwendungen des 
Arbeitsplatzcomputers auf der Basis einer Multi- 
Mikrocomputerstruktur gemacht. Dieser Beitrag 


1 Testmöglichkeiten 


Testmöglichkeiten von hochintegrierten Baustei- 
nen bei der Herstellung und im Betrieb sind entweder 
unzureichend oder zu aufwendig. Es sind verschie- 
dene Möglichkeiten denkbar, dieses zu beheben |1}: 
-Einbeziehung von Zufallstestmustern und algo- 

rithmisch erzeugten Tests in Funktionstests. 

— Zusammenarbeit zwischen Hersteller und Anwen- 
der, um einen besser testbaren Schaltungsentwurf 
zu erzielen. 

Auf der Chipebene scheint dieser zweite Punkt in 
absehbarer Zeit nicht realisierbar zu sein, da kein Her- 
steller bereit ist, Design-Unterlagen der Bausteine 
weiterzugeben. 

Berücksichtigt man weiterhin die zunehmende 
Komplexität beim Übergang von Einzelbausteinen 
zum Rechner auf einer Platine, vom Einzelmikrocom- 
puter zum Mehrrechnersystem, so bleibt für den An- 
wender nur der Weg: Test und Diagnose muß bereits 
beim Entwurf der Systeme berücksichtigt werden 
12,3]. Ein besonderes Beispiel ist der Entwurf der 
Mehrrechnerstruktur M3R |2|. 

Welche Testmöglichkeiten bieten sich an? Ver- 
schiedene Verfahren werden beschrieben als 
— Testverfahren während der Chip-Herstellung, 

— Prüfung fertiger Bausteine |1.. 

In |1| werden auch detailliert Testmethoden für Mi- 

kroprozessoren angegeben. In |4| werden verschie- 

dene Verfahren aufgezählt: 

— Simulation der Logik, 


berichtet über eingesetzte Test- und Prüfverfahren 
dieses Systems. Darüber hinaus werden Hinweise 
für die praktische Realisierung und Konstruktion 
derartiger Rechner gegeben, die erprobt wurden 
und damit zur Nachahmung empfohlen werden. 


— Vergleichsmethode, 
— Zufallsmethode. 

Diese Tests umfassen hauptsächlich die Prüfung 
einzelner hochintegrierter Bausteine und nicht den 
Test von Systemen. Ein Weg in Richtung des System- 
tests liegt im funktionellen Leiterplattentest |5, 6, 7), 
der hauptsächlich im Prüffeld Verwendung findet. 


Im folgenden wird auf Methoden eingegangen, die 
bei der Entwicklung von Mikrocomputersystemen, 
wie bei dem in dieser Serie beschriebenen Arbeits- 
platzcomputer, Verwendung gefunden haben. 


2 Hilfsmittel zur Entwicklung von Mikrocompu- 
tersystemen 


Für einfache Mikrocomputeranwendungen bieten 
sich problemlose, leicht zu bedienende Testgeräte an 
'8, 9], die darüber hinaus auch den Vorteil haben, für 
Lern- und Schulungszwecke eingesetzt werden zu 
können. Bei größeren und damit komplizierteren Sy- 
stemen muß man jedoch umfassendere Testmöglich- 
keiten einsetzen. Dazu kennt man heute zwei Katego- 
rien von Verfahren: 

— Logikanalysatoren, 
— In-Circuit-Emulatoren. 


2.1 Logikanalyse 


Logikanalyse bedeutet die Auswertung digitaler In- 
formationen zum Zwecke der Überprüfung ihrer Rich- 
tigkeit. Ein Hilfsmittel hierfür ist der Logikanalysator, 
der durch den verstärkten Einsatz der Mikroprozesso- 
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ren seinen Siegeszug angetreten hat. Der Einsatz die- 
ses Werkzeugs ist von Mitarbeitern der bekanntesten 
Hersteller in |10, 11, 12] beschrieben worden. Das 
Grundprinzip des Logikanalysators liegt in der paral- 
lelen Aufzeichnung (Speicherung) von Informationen 
(statischer Art: Daten, dynamischer Art: Störimpul- 
sen), wenn bestimmte Suchbedingungen gegeben 
sind (Trigger). Das Gerät kann dabei sowohl für die 
Programmentwicklung, wie auch für die Hardware- 
entwicklung eingesetzt werden. 


2.2 In-Circuit-Emulation 


Auf einer höheren logischen Stufe anzusiedeln ist 
die Methode der In-Circuit-Emulation |13|. Sie unter- 
stützt vor allem den Programmentwickler. In dieser 
Phase wird in einem Entwicklungssystem (vollstän- 
diges Mikroprozessorsystem, z.B. Siemens-Mikro- 
computer-Entwicklungssystem SME 800 114]) ein 
Programm erstellt (Texteditor), übersetzt (Compiler) 
und getestet (Emulator). Dieser Vorgang ist streng ge- 
nommen der einer Simulation, wie sie auf Host-Rech- 
nern durchgeführt wird. 

Im nächsten Schritt wird dann das zu entwickelnde 
Prototypensystem mit dem Entwicklungssystem über 
das In-Circuit-Emulationssystem (z.B. Emulation- 
und Testadapter ETA80|15)) verbunden (Bild 1). Dazu 
wird an Stelle des Mikroprozessors des Prototypensy- 
stems das Emulatorsystem gesteckt. Entwicklungssy- 
stem und Prototypensystem sind dann über eine „Na- 
belschnur‘‘ miteinander verbunden. Dabei wird dieim 
ersten Schritt entwickelte Software zunächst noch im 
Entwicklungssystem ablaufen. Erst dann, wenn keine 
schwerwiegenden Hardwarefehler im Prototypensy- 
stem festgestellt werden (‚fatal errors“), wird die 
Software segmentweise (Datenbereich, Programmbe- 
reich, Stackbereich) in die Speicher des Prototypensy- 
stems ausgelagert. 

Anschließend wird die Peripherie getestet. Schließ- 
lich wird die „Nabelschnur“ entfernt, der vorher ent- 
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fernte Prozessor ins Prototypensystem gesteckt und 
ein erster Lauf unter realen Verhältnissen versucht. 


2.3 Kombination beider Verfahren 


In sehr vielen Fällen wird man mit den beschriebe- 
nen Methoden - getrennt eingesetzt - Erfolg haben. In 
kritischen Fällen muß man sie kombinieren. Man 
spricht dann vom „hardware trace‘ | 13. Der Logikana- 
lysator gibt dabei Auskunft über Zeitverhalten. Er 
speichert Bussignale und die Zyklen einzelner Befeh- 
le. 





In besonders zeitkritischen Fällen muß man abeiner 
gewissen Stufe der Entwicklung auf die Emulation 
ganz verzichten, da sie nie unter Echtzeitbedingungen 
ablaufen kann. 


3 Weitere Hilfsmittel für die Entwicklung 
des Arbeitsplatzcomputers 


Für den Aufbau des Arbeitsplatzcomputers wurden 
zusätzliche Methoden entwickelt, die die Hardware 
sowohl auf der Einzelrechnerebene testen, wie auch 
den Verbundbetrieb dieser Mehrrechnerstruktur 
(siehe Teil 1 und 2 dieser Aufsatzreihe). 


3.1 Einzelrechner 


Zum Test der Einzelrechner (CPU, Speicher, Peri- 
pherie) wurde ein Test- und Diagnoseadapter für die 
Bussignale entwickelt (Bild 2). Er wird über eine Ent- 
kopplungsschaltung an den Bus des Mikrocomputers 
angeschlossen. Die nachgeschaltete Elektronik wertet 
die Bussignale aus und erzeugt entsprechende Steuer- 
signale für die Anzeigen. Damit können alle Bussi- 
gnale dauernd beobachtet werden. Im Fehlerfall läßt 
sich dann schnell feststellen, mit welchen Hilfsmit- 
teln und in welcher Richtung zur Fehlereingrenzung 
weiter gearbeitet werden muß. 

Über unterschiedlich farbige Leuchtdioden werden 
für jedes Steuersignal zwei Zustände angezeigt: 


Der momentane und der 
vorhergehende Zustand. 
Die Hexadezimal-Anzeigen 
des Daten- und Adressen- 
busses werden mit den Zu- 
griffssignalen getriggert. 
Bleibt der Mikrocomputer 
stehen, kann man mit Hilfe 
des Adapters folgende Fra- 
gen rasch beantworten: 
Welcher Art war das letzte 
Steuersignal? Unter welcher 
Adresse wurde zugegriffen? 
Welches Datum war dieser 
Adresse zugeordnet? Über 
Schalter kann man wählen, 
welches oder welche Kom- 
bination von Bussignalen 
zur Triggerung herangezo- 
gen werden (dies gilt auch 
für beliebige Kombinatio- 
nen der Daten- oder Adres- 
seninformationen). 
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„Bild 2. Blockschaltung des Diagnose- und Testadapters 


Jedes Bus-Steuersignal wird miteiner nachtrigger- 
baren monostabilen Kippstufe verlängert, damitauch 
kurze Einzelreaktionen erkannt werden können. Dar- 
über hinaus können Haltepunkte gesetzt werden, so 
daß in kritischen Fällen auch im Single-Step-Verfah- 
ren gearbeitet werden kann. 


Auf dem Einzelrechner laufen Testprogramme für 
die Einzelfunktionen des Rechners ab: 
— GPU-Test 
— Speichertestroutinen 
— Peripherietests 


Dabei wird auf das Selbsttestverfahren von Mikro- 
rechnern zurückgegriffen |16, 17. Damit lassen sich 
beim Urladen des Systems nach Einschalten der 
Stromversorgung und in regelmäßigen Zeitabständen 
beim späteren Systemlauf Aussagen über den Funk- 
tionszustand des einzelnen Mikrocomputers machen. 

Ein wichtiges Hilfsmittel ist dieSpannungsüberwa- 
chung von Mehrspannungsnetzgeräten für die Mikro- 
computer (Bild 3). Erfahrungsgemäß denkt man an 
das fehlerhafte Arbeiten des Netzteils bei der Fehler- 
suche immer erst zuletzt, meist wenn man mit der lo- 
gischen Fehlersuche nicht mehr weiterkommt. Dazu 
ist es sinnvoll, das Überschreiten 
bzw. Unterschreiten von Toleranz- 
werten der einzelnen Quellen 
mit Leuchtdioden anzuzeigen, 
um so in Abhängigkeit von einer 
Referenzspannung den augen- 
blicklichen Zustand ablesen zu 
können. 

Als sinnvoll hat sich auch der 
Anschluß einer Diagnosekonsole 
erwiesen, über die Zugriff zu den 
auf Lesespeichern (ROMs oder 
PROMs) vorliegenden Testpro-, 
grammen möglich ist. Diese Kon- 
sole erlaubt auch die Steuerung 
des Testablaufs durch den Ent- 
wickler (beim späteren Einsatz: U 
durch den Benutzer) abhängig 
vom Testfortschritt, der am Bild- 
schirm angezeigt werden kann. 
Im einfachsten Fall wird dazu die 
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Ein-/Ausgabeeinrichtung verwendet, über die der Be- 
nutzer normalerweise mit dem System verkehrt. 


3.2 Mehrrechnerstruktur 


Die einzelnen Mikrocomputer werden, wie in Teil 1 
und 2 dieser Reihe beschrieben, über ein Kommunika- 
tionssystem (Bus) miteinander verbunden. Für den 
Test des Gesamtsystems werden sämtliche Einzeltest- 
verfahren, wie vorstehend beschrieben, benutzt. Dar- 
über hinaus wurden noch weitere Möglichkeiten ge- 
schaffen: 


Auf den Bussteuerbaugruppen jedes Rechners sind 
Anzeigen vorgesehen, um über den aktuellen Zustand 
des Kommunikationssystems jeder Zeit informiert zu 
sein. Damit wird der Kommunikationszustand jedes 
Einzelrechners angezeigt. Darüber hinaus gibt es Ein- 
griffsmöglichkeiten auf den einzelnen Rechner, die es 
ermöglichen, einen defekten Rechner vom übrigen 
System zu isolieren und abzuschalten (für Wartungs- 
zwecke) bzw. wieder dazuzuschalten. 

In jedem Rechner liegen auf PROMs Testpro- 
gramme für die Kommunikation vor, die vorallem den 
Test zeitkritischer Abläufe ermöglichen. Um ein ge- 
zieltes Starten dieser Programme in allen Rechnern 
gleichzeitig zu initialisieren, wurde eine Zusatzschal- 
tung entwickelt, die es erlaubt, den Ausgang der Dia- 
gnosekonsole parallel auf alle Diagnoseeingänge der 
einzelnen Rechner zu schalten und die Rechner zur 
Aufnahme dieser Information zu unterbrechen. Dar- 
über hinaus kann der Diagnoseausgang eines beliebi- 
gen Rechners (schaltbar) angezeigt werden. 


4 Testhilfen während des Systemlaufs 


Für den Test der Einzelkomponenten einer Mehr- 
rechnerstruktur und des gesamten Systems sind ver- 
schiedene Strategien denkbar. Hier wurde die Me- 
thode gewählt, einen Funktionsrechner für Diagnose 
und Test entweder temporär (zu den anderen Aufga- 
ben) oder ausschließlich zu benutzen. Über diesen 
Rechner werden beim Einschalten des Systems (Urla- 
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Bild 4. Prototyp des Arbeitsplatzcomputers (Laboraufbau) 


den) und in bestimmten Zeitabständen (einstellbar 
über Timer) Testprogramme auf den einzelnen Kom- 
ponenten des Systems initialisiert, die Ergebnisse ge- 
sammelt und ausgewertet. 

Werden fehlerhafte Ergebnisse ermittelt, so erfolgt 
eine weitergehende Prüfung des Rechners, die nach 
einer Testwiederholung (um Zufallsfehler auszu- 
schließen) und Fehlerwiederholung zur Abschaltung 
führt. Das übrige System arbeitet weiter. Die Aufgaben 
des abgeschalteten Rechners werden nach einer mög- 
lichen Neukonfiguration von den anderen übernom- 
men. Der abgeschaltete Rechner wird angezeigt und 
kann nun vom Benutzer (Wartungstechniker) für Re- 
paraturmaßnahmen ausgewechselt werden. 

Eine ausgetauschte Baugruppe wird durch den Dia- 
gnoserechner getestet, ehe eine Neukonfiguration des 
Systems mit dem ursprünglichen Ausbau durchge- 
führt wird. 


5 Konstruktive Maßnahmen 


In den vorangegangenen Teilen dieser Serie wurden 
generelle und detaillierte Aussagen über Prinzip, 


Sinn, Ablauf von Prozessen einer Mehrrechnerstruk- 
tur und einige Anwendungen gemacht. Der Nachweis 
der Gültigkeit läßt sich jedoch erst durch den Aufbau 
eines Prototypensystems erbringen (Bild 4). Gewählt 
wurde die Form eines Kompaktgerätes, in dem alle 
Teile untergebracht sind und das — im Unterschied 
zum Tischmodell- keine dauernde Standfläche benö- 
tigt, sondern bei Bedarf an den Schreibtisch des Bear- 
beiters geschoben werden kann. 

Hier schließt sich der Bogen zu der eingangs er- 
wähnten Forderung: Test und Diagnose muß bereits 
beim Entwurf eines Systems berücksichtigt werden. 
Bild 5a zeigt den Rechnerblock von der Vorderseite. 
Man erkennt als Baugruppenträger sogenannte „card 
cages‘‘, die jeweils einen Mikrocomputer darstellen 
(im Bedarfsfall können mehrere ‚card cages“ einen 
Rechner bilden). Es wurden Standardplatinen des Sy- 
stems SBC 8020 und 8612 mit den entsprechenden 
Erweiterungsplatinen verwendet. Man sieht ebenfalls 
die Bussteuerplatinen in jedem Rechner mit den An- 
zeige-LEDs. Bild 5b zeigt den Rechnerblock von der 
Rückseite. Hier werden die beiden Bussysteme sicht- 
bar: 

— der interne Bus der einzelnen Mikrocomputer, der 

Bestandteil der Baugruppenträger ist, 

— der Kommunikationsbus für den Verkehr der Rech- 
ner untereinander (steckbare Leiterplatten im unte- 
ren Teil des Bildes). 


Der Kommunikationsbus wurde im Sinne der Feh- 
lererkennung so bemessen, daß hier nicht mit TTL- 
Pegel (0...5 V), sondern mit symmetrischen Signalen 
und hohem statischen Störabstand gearbeitet wird 
(+12 V). Dafür wurden Treiber- und Empfängerbau- 
steine von Texas Instruments (SN 75150 und 75154) 
verwendet. Außerdem wird auf dem Bus das Verfah- 
ren der Paritätssicherung eingesetzt. 

Schließlich wird im Sinne der Modularität der Ein- 
zelkomponenten des Systems keine gemeinsame 
Stromversorgung verwendet. D. h. jeder Rechner hat 
sein eigenes Netzgerät, das oberhalb der ‚card cages“ 
angeordnet ist (s. Bild 5). Der Anschluß an die 220- 
V-Versorgung geschieht nur einmal, so daß hier von 
einem dritten Bus zu sprechen ist. 
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6 Schlußbemerkungen 


'Es hat sich gezeigt, daß die Maßnahmen für Test 
und Diagnose, die bereits beim Entwurf dieses Sy- 
stems getroffen wurden, einen erheblichen Einfluß 
auf die Stabilität und Sicherheit des Systems im prak- 
tischen Einsatz hatten. Man istsich bewußt, daß damit 
keine endgültigen Ergebnisse erzielt werden konnten. 
Das Problem des Tests von Mehrrechnerstrukturen 
wird weiter untersucht. Hoffnungsvolle Ansätze in 
Richtung verteilter In-Circuit-Emulationssysteme bie- 
ten sich an. Man hofft, darüber in einem weiteren Auf- 
satz berichten zu können. 
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Ing. (grad.) Horst Huse 


Multi-Mikrocomputer-System 


modular aufgebaut 


Leistungsfähige 16-Bit-Mikroprozessoren erlauben die 
Realisierung kompakter Module für Mehrrechnersy- 
steme mit direkter Kopplung über den Systembus. Im 
Gegensatz zu dezentralen, meist über serielle Bussy- 
steme lose gekoppelten Mehrrechnersysteme [1] wird 
die Systemkopplung dazu verwendet, bereits inner- 
halb eines 19-Zoll-Einbaurahmens die Rechenleistung 
zu erhöhen. Anstelle einer kostspieligen und unüber- 
schaubaren Zentralisierung werden Systeme mit einer 
funktionsorientierten Architektur angestrebt [2]. Die- 


1 Warum Multi-Mikrocomputer-Systeme? 


In den letzten Jahren wurde bei Mikroprozessoren 
eine beachtliche Leistungssteigerung durch Verbesse- 
rung der Architektur, Erweiterung des Befehlssatzes und 
Einsatz kleiner Halbleitergeometrien (z.B. SMOS - 
„Scaled MOS“) erzielt. Oft kann die höhere Geschwin- 
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ses setzt voraus, daß der Systembus einen hohen 
Datendurchsatz erlaubt und Multiprozessorfähigkeit 
besitzt. Außerdem muß der mechanische Aufbau aus- 
reichende Flexibilität bieten, wie z. B. Mischbarkeit 
von zwei Platinengrößen innerhalb eines Einbaurah- 
mens. Diese Forderungen werden bei Verwendung 
des E-BUS als genormte Systemschnittstelle erfüllt 
[3]. Dieser Beitrag beschreibt Möglichkeiten, Grenzen 
und Vorteile der Systembuskopplung anhand eines 
praktischen Beispiels. 


digkeit (z. B. Speicherzykluszeiten von <200 ns) auf der 
Systemebene nicht wirtschaftlich genutzt werden. Der 
Datendurchsatz wird durch die Zugriffszeit der Spei- 
cher, die Durchlaufverzögerungszeit der Treiber und die 
Geschwindigkeit der Ein-/Ausgabe begrenzt. Wird ein 
zentrales Mikrocomputersystem z. B. unter Verwendung 
von ECL-Logik oder eines 32-Bit-Rechners für einen 
höheren Datendurchsatz konzipiert, so steigen die 
Kosten überproportional an. Es ist aus diesem Grunde 
oft wirtschaftlicher, in industriellen Systemen noch 
höhere Systemleistungen durch den Einsatz mehrerer 
kostengünstiger 8- oder 16-Bit-Mikroprozessoren anzu- 
streben. Möglichkeit dazu bietet die Verwendung von 
Mikroprozessoren und Baugruppen mit komplexeren 
Funktionen, wie z.B. Kommunikations- und Ein-/Aus- 
gabesteuerungen. Durch die Intelligenz der Ein-/Ausga- 
bemodule lassen sich Teile der Software des zentralen 
Mikroprozessors (Master) in den Peripherie-Mikrocom- 
puter (Slave) verlagern. Aus einem zentralisierten 
Mikrocomputersystem wird ein dezentralisiertes Multi- 
Mikrocomputersystem. So kann z. B. in der Software des 
Peripherie-Mikrocomputers ein HDCL-Übertragungs- 
protokoll oder Floppy-Disk-Dateiorganisation realisiert 
werden. 

Bei industriellen Anwendungen lassen sich auch zeit- 
kritische Aufgaben wie Regelkreise oder Positionierun- 
gen in einen „intelligenten“ Peripheriemodul verlagern. 
Voraussetzung ist jeweils, daß der Peripherie-Mikro- 
computer mit dem Master kommunizieren kann und 
Zugriff zu den notwendigen Ein-/Ausgabeinformationen 


hat. 


Bei größeren Systemen werden bestimmte Funktionen 
(Prozesse) oder ganze Programmodule (Tasks) auf meh- 
rere Multi-Mikrocomputermodule (MMC-Module) ver- 
teilt. Sind in einem System komplexe und zeitkritische 
Berechnungen notwendig, wie z.B. dreidimensionale 
Bahnberechnungen, sollte diese Aufgabe einem einzel- 
nen Modul übertragen werden. 

Die Verteilung der Gesamtfunktion des Systems auf 
parallel arbeitende Multi- oder Peripherie-Mikrocompu- 
termodule (Bild 1) bietet außer der höheren Systemlei- 
stung noch folgende Vorteile: 
© Entlastung des zentralen Mikrocomputers von zeit- 

kritischen Abläufen. 
® Aufteilung eines großen zentralen Softwarepaketes in 

mehrere kleinere und damit wartungsfreundlichere 

Programme. 
® Vermeidung des überproportional steigenden Spei- 

cher- und Programmverwaltungsaufwandes von gro- 

ßen zentralisierten Systemen. 
® Einfachere Überwachungsmöglichkeiten durch paral- 
lel arbeitende Mikrocomputer während des Betriebes. 
Speziell die steigenden Anforderungen an die Fehlersi- 
cherheit industrieller Systeme lassen sich mit Multi- 
Mikrocomputerstrukturen wirtschaftlich vertretbar rea- 
lisieren, da gezielt Redundanz eingeplant werden kann. 


2 Kopplung der Mikrocomputer-Hardware 


Dezentralisierte Mikrocomputermodule werden ent- 
weder für eine bestimmte Funktion, z. B. Datenübertra- 
gung oder Lageregelung, oder als universell einsetzbare 
Multi-Mikrocomputermodule ausgelegt. In beiden Fäl- 
len muß sichergestellt sein, daß der Mikrocomputer 
Zugriff zu den notwendigen Ein-/Ausgabeinformationen 
hat, und mit dem Master kommunizieren kann. Die 
Wahl des Kommunikationsweges zum Master ist davon 
abhängig, ob ein direkter Zugriff zu Speicher- oder Ein-/ 
Ausgabemodulen am Systembus erforderlich ist oder 
nicht. 

Ist dieses nicht der Fall, d. h. der erforderliche Spei- 
cher und die Ein-/Ausgabeverbindungen befinden sich 


auf der Platine, kann die Kommunikation zum Master 
durch eine lose Kopplung beider Bussysteme realisiert 
werden. Ist ein Zugriff auf Module am Systembus not- 
wendig, muß eine enge Buskopplung vorgesehen wer- 
den. Diese Art der Kopplung ist auch dann erforderlich, 
wenn der Slave-Modul bei Ausfall des Masters dessen 
Aufgaben teilweise übernehmen soll. 


2.1 Lose Buskopplung 


Die lose Buskopplung zwischen zwei Bussystemen 
dient zur Kommunikation zwischen Master- und Slave- 
Mikrocomputermodulen und wird mittels einer Koppel- 
einheit realisiert (Bild 2). Art und Größe der Koppelein- 
heit ergibt sich aus der Datenmenge und der Geschwin- 
digkeit, mit der die Kommunikation erfolgen soll. 

Bei der einfachsten Art der Kommunikation wird ein 
Slave-Modul durch einen Interrupt vom Master zur Aus- 
führung einer definierten Funktion veranlaßt. Der Slave 
meldet die korrekte Ausführung wiederum durch einen 
Interrupt zum Master. Sollen Parameter oder ganze 
Datenblöcke zwischen beiden Modulen ausgetauscht 
werden, müssen die Kommunikationsmöglichkeiten 
erweitert werden. 

Es stehen dem Systementwickler drei weitere Mög- 
lichkeiten zur Auswahl: 
® Kopplung über Speicherworte, 

@ Ein-/Ausgabeports oder den 

@ DMA-Speichertransfer. 

Außer bei der DMA-Kopplung wird der Systembus 
durch Zugriffe des Slave-Moduls auf die Koppeleinheit 
nicht belastet. Bei allen drei Kopplungsarten ist auch 
eine „Multiprozessorfähigkeit“ des Systembusses nicht 
zwingend erforderlich. Aus diesen Merkmalen resultie- 
ren die wichtigsten Eigenschaften der losen Buskopp- 
lung. 


2.1.1 Kommunikation über Speicherworte 





Für die Kommunikation über Speicherworte wird ein 
spezieller Speicherbereich so ausgelegt, daß er inner- 
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halb des Adreßbereichs des Master- und Slave-Moduls 
liegt. Es handelt sich somit um einen Bereich, der von 
zwei Seiten adressierbar ist, und wird deshalb als zwei- 
seitiger Speicher oder „Dual-Port-Memory“ (DPM) 
bezeichnet. Das Beispiel in Bild 3 zeigt einen 2 KByte 
großen Speicherblock, welcher innerhalb des 1 MByte- 
Adreßbereiches des Masters und des 64-KByte-Berei- 
ches des Slaves liegt. 
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Die absoluten Adressen für beide Seiten des DPMs 
sind frei wählbar. Werden normale RAM-Speicherbau- 
steine, z. B. der Typ TMS 4016 (2 K x 8 Bit organisiert), 
für das DPM verwendet, so kann nicht gleichzeitig von 
zwei Seiten gelesen bzw. geschrieben werden. Durch 
eine Zugriffsteuerung wird aus dem einfachen Speicher 
ein Pseudo-DPM (Bild 4). Die aus der Adreßdecodierung 
generierten Speicheranforderungen werden von der 
Zugriffslogik ausgewertet. Ist der Zugriff von nur einer 
Seite gewünscht, so erhält diese sofort eine Zuteilung. 
Treten beide Anforderungen gleichzeitig auf, hat der 
Systembuszugriff Vorrang. Der Speicherzyklus des Sla- 
ves oder Masters kann über die Steuerung der READY- 
Signale verzögert werden. Das Pseudo-DPM führt in der 
Regel zu keiner nennenswerten Erhöhung der System- 
busbelegung. Die Festlegung der Funktion bzw. die 
Bedeutung einzelner Speicherworte des DPMs wird an 
Hand der Kommunikationsanforderungen festgelegt. 
Speicherstellen die für den Master als Schreib-/Lese- 
RAM definiert sind, dürfen vom Slave nur gelesen wer- 
den. Dies gilt umgekehrt ebenso für den Master. Eine 
interruptgesteuerte Kommunikation ist dadurch reali- 
sierbar, daß beim Schreiben auf eine bestimmte Spei- 
cheradresse automatisch ein Interrupt für den Master 
bzw. den Slave erzeugt wird. 

Ist die Menge der auszutauschenden Daten gering, so 
ist ein kleiner Speicher mit schnellen Registerbaustei- 
nen, wie den Typen SN74SL170 bzw. ’LS670, ausrei- 
chend. Da diese Bausteine gleichzeitiges Lesen und 
Schreiben erlauben, kann auf eine Zugriffslogik verzich- 
tet werden. Bild 5 zeigt das Blockdiagramm eines DPMs 
mit je 4 Registern zu 8Bit für die Kommunikation 
Master > Slave und Slave > Master. Der sequentielle 
Transport mehrerer Datenbytes über ein Register wird 
durch eine einfache Handshake-Prozedur per Interrupts 
oder Softwareflags realisiert. Ein Beispiel der Register- 
definition des DPMs für einen einfachen Regelkreis. 
(Drehzahl- oder Positionssteuerung) zeigt Bild 6. Es ist 
zu beachten, daß bei der Realisierung des DPMs nach 
Bild 5 geschriebene Wörter nicht wie beim Pseudo-DPM 
wieder auslesbar sind. Das Register-DPM zeichnet sich 
durch kurze Zugriffszeit (<50 ns) und geringen Aufwand 
in der Hardware aus. 


2.1.2 Kommunikation über Ein-/Ausgabeports 


Die Kommunikation zu Slave-Mikröcomputern ist 
ebenso über Ein-/Ausgabeports realisierbar. Analog zum 
DPM muß ein zweiseitiges E/A-Port realisiert werden. . 
Dieses liegt wiederum im E/A-Adreßbereich des Masters 
und Slaves (Bild 3). Sind die Anforderungen an Daten- 
menge und Geschwindigkeit gering, läßt sich diese Art 
der Buskopplung am einfachsten aufbauen. Der Daten- 
austausch wird über Handshake-E/A-Ports und/oder 
Interrupts gesteuert, um den Leistungs- und Hardware- 
aufwand gering zu halten. 

Einfache intelligente Peripheriesteuerungen mit Ein- 
chip-Mikrocomputern (uC) können so effektiv an den 


Systembus gekoppelt werden (Bild 9). Im Gegensatz zur 
DPM-Kopplung gehen keine Speicheradressen verloren, 
wenn der Master-Mikrocomputer über einen separaten 
Ein-/Ausgabeadreßbereich verfügt. Ist der E/A-Bereich 
am Systembus und uP-Bus groß genug, so kann auch 
eine Kopplung mittels DPM, adressiert über E/A-Adres- 
sen,«vorgenommen werden. 


2.1.3 Datentransfer per DMA 


Peripherie-Mikrocomputermodule, die größere Daten- 
blöcke’mit hoher Geschwindigkeit transportieren müs- 
sen, sollten über einen direkten Systemspeicherzugriff 
verfügen. Dieser schnelle DMA-Kanal wird direkt vom 
Master oder, an Hand der im DPM übergebenen Parame- 
ter, vom Slave initialisiert. Die sich aus dem DMA- 
Transfer ergebende zeitliche Belastung des Systembus 
ist geringer als die eines programmierten Datentransfers 
des Masters vom DPM zum Systemspeicher. Ist der 
Systembus nicht multiprozessorfähig, wird der Master- 
und Slave-Mikrocomputer während des DMA-Transfers 
in den HOLD-Mode gesteuert. Für den multiprozessorfä- 
higen E-BUS stellt eine DMA-Steuereinheit einen Bus- 
master dar und muß deshalb über einen Buszuteiler 
(Arbiter) verfügen. Das typische Blockdiagramm eines 


Bild 8. Peripheriegerätesteuerungen, wie z.B. Floppy- 
oder Hard-Disk, Grafik-Display oder schnelle Achsen- 
steuerungen, sind mit dieser Konfiguration effektiv zu 
realisieren. Der Slave-Mikrocomputer muß über mög- 
lichst viel lokalen Programm- und Datenspeicher verfü- 
gen, so daß auch komplexere Programme vom Master in 
den Slave verlagert werden können. Besteht eine Soft- 
warekompatibilität zwischen beiden, ist eine Übertra- 
gung der Software ohne größere Änderungen zu reali- 
sieren. 


2.1.4 Lose Kopplung in großen Systemen 


Ist eine größere Anzahl von Ein-/Ausgabeverbindun- 
gen notwendig, und sind diese nicht auf einem Modul 
herzustellen, ist eine Erweiterung des lokalen uP-Bus 
möglich. Sie kann auf mehrere Arten realisiert werden. 
Die einfachste Methode sind sogenannte „Piggy-Packs‘“; 
kleine Module, die direkt auf das Mikrocomputermodul 
gesteckt werden und eine begrenzte Speicher- oder Ein-/ 
Ausgabeerweiterung zulassen. 

Für industrielle Ein-/Ausgabeeinheiten ist diese Art 
jedoch nicht einsetzbar, da Steckverbinder und Kriech- 
strecken nicht den VDE-Bestimmungen entsprechen. 
Standard-Ein-/Ausgabemodule, welche auf den lokalen 
uP-Bus oder einen Systembus ausgelegt sind, erfüllen 
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Verwendung des Doppel-Europakartenformates (230 X 
160 mm?) der zweite Busstecker für einen lokalen uP- 
Bus oder einen zweiten E-BUS vorgesehen (Bild 9). Der 
zweite E-BUS ist, bei Verwendung einer Untermenge 
von Signalen, als einfacher E/A-Bus ausführbar. Die 
Untermenge für die industrielle bitserielle Ein-/Ausgabe 
(CRU) umfaßt nur 11 Leitungen. Bei geeigneter Puffe- 
rung ist der Anschluß von „Remote-“ Ein-/Ausgabe- 
steckrahmen mit einer Entfernung von bis zu 30 m, 
möglich. Ist die Anzahl der Einschübe innerhalb eines 
19-Zoll-Steckrahmen für ein größeres Multi-Mikrocom- 
putersystem nicht ausreichend, so ist in den meisten 
Anwendungen eine lose Kopplung mehrerer Steckrah- 
men sinnvoller, als eine „Verlängerung“ des Systembus- 
ses. Bei einer Verlängerung wird der Datendurchsatz des 
Systembus durch zusätzliche Pufferung und größere Lei- 
stungslängen verringert. Die Leistungsgrenze des 
Systems wird herabgesetzt. Steht dagegen pro Steckrah- 
men ein Systembus mit mindestens einem uC-Modul 
zur Verfügung, wird der Datendurchsatz des Gesamtsy- 
stems durch Parallelverarbeitung erhöht. Innerhalb 
eines Steckrahmens können wiederum mehrere Mikro- 
computer an einem Systembus arbeiten. 

Die Kommunikation der Teilsysteme untereinander 
wird über „Message-Channels“ vorgenommen. Wie 
schon bei der losen Kopplung von Peripherie-Mikro- 
computermodulen bestimmt die auszutauschende 
Datenmenge die Art der Kopplung. Beschränkt sich die 
Datenmenge auf einige Parameter, Status- und Steuerin- 
formationen, reicht eine Registerkopplung aus (Bild 5). 
Ist eine blockorientierte Kommunikation erforderlich, 
bietet sich ein Multi-Port-Memory (MPM) an. Der Hard- 
wareaufwand läßt sich durch den Einsatz eines Pseudo- 
MPMss auf ein akzeptables Maß begrenzen. 

Mechanisch problemlos ist eine Realisierung, wenn 
die Teilsysteme im standardisierten Europakartenformat 


aufgebaut sind. Durch die festgelegten Teilungseinhei- 
ten können Platinen mit einem ganzen Vielfachen der 
Höheneinheiten verwendet werden, um Teilsysteme mit 
horizontalen Systembus vertikal zu koppeln. Bild 10 
zeigt als Beispiel ein System mit drei Teilsystemen. Die 
Teilsysteme werden über ein Buskoppler-Modul lose 
gekoppelt. 

Das Buskoppler-Modul verfügt über einen Kommuni- 
kations-Bus, die Pufferung zum Systembus der Teilsy- 
steme, eine Zugriffssteuerung und den RAM-Speicher. 

Auf dem Modul ist zusätzlich noch ein Überwa- 
chungs-Mikrocomputer zur Erhöhung der Fehlersicher- 
heit und/oder Koordinierung der Teilsysteme ein- 
setzbar. 

Sollen alle drei Teilsysteme miteinander über „Mes- 
sage-Channels“ verbunden werden, sind hierzu sechs 
Speicherblöcke (z. B. mit je 256 Byte) im Kommunika- 
tionsspeicher notwendig. 


2.2 Enge Buskopplung 


Die enge Kopplung eines lokalen uP-Bus an den 
Systembus wird immer dann notwendig, wenn Multi- 
Master- oder redundante Systeme aufzubauen sind. Die 
Kommunikation zwischen den Multi-Mikrocomputer- 
modulen wird über gemeinsame Speicherbereiche am 
Systembus vorgenommen. 

Die enge Buskopplung setzt voraus, daß der System- 
bus multiprozessorfähig ist. Dieses Merkmal läßt es zu, 
mit mehreren Bus-Mastern an einem Systembus zu 
arbeiten. Das wichtigste Merkmal der engen Buskopp- 
lung ist die Tatsache, daß ein Bus-Master, welcher die 
Kontrolle über den Systembus besitzt, auch Zugriff zu 
allen passiven Modulen am Bus hat. Das sind z.B. 
Speicher-, Ein-/Ausgabe- oder Peripheriemodule. Auch 





‚9-Zl- 7 
£ _Einbaurahmen 
E-System 1 


Buskoppler-Modul 












Zugriffs- 
Steuerung 





Kommuni- 
kations - 
Speicher 

(RAM) 









name ME E-systena 
| Supervisor— N 
I pe N 
keunand 





BEN... 2. 2: 
D= Decodierung 

Bild 10. Lose Kopplung von 

Einfach-Europakarten über Buskoppler-Modul 








Ein-/Ausgabe- 
Modul 


Buszuteiler 


IR Tr 
.4# “ 
Buszuteiler f 


* 


| 





Bild 11. Multi-Mikroprozessor-System 








62 


der Speicher eines Master-Moduls kann, wenn er vom 
Systembus her adressierbar ist, ein passiver Busteilneh- 
mer sein. Dieses wird z.B. zum Laden größerer Pro- 
gramme von einem Massenspeicher verwendet. 

Äußerst bedeutend für die Beurteilung der Möglich- 
keiten und Grenzen der engen Buskopplung ist, daß der 
Datendurchsatz des Systembus festliegt. Arbeiten meh- 
rere.Master am Bus, so muß die zur Verfügung stehende 
Buszeit aufgeteilt werden. Die Anzahl der möglichen 
Master ist daher um so größer, je kleiner die Busbele- 
gung des einzelnen Bus-Masters ausfällt. Die Realisie- 
rung einer engen Kopplung von Mikroprozessormodu- 
len (hur Zentraleinheit, ohne lokalen Programm- oder 
Datenspeicher), wie sie Bild 11 zeigt, ist bei Verwen- 
dung moderner 16-Bit-Mikroprozessoren nicht mehr 
sinnvoll. Beim Typ TMS 9995 werden z.B. Befehle 
überlappend verarbeitet, und die Speicherschnittstelle 
ist zum Teil bereits zu 80 % ausgelastet. Selbst bei einem 
komplexen Befehl, wie der vorzeichenlosen 16 X 16-Bit- 
Multiplikation (32-Bit-Ergebnis in 7,67 us), geht die 
Belegung höchstens auf ca. 20 % zurück. 

Ein Master-Modul am Systembus sollte deshalb über 
viel lokalen Programm- und Datenspeicher sowie Ein-/ 
Ausgabe verfügen (Bild 12). In diesem Fall beschreibt 
die Bezeichnung Multi-Mikrocomputer-System die 
Struktur eindeutiger als der häufig verwendete Global- 
begriff „Multiprozessorsystem“. 

Eine weitere Möglichkeit, die Systembusbelastung zu 
reduzieren und die Geschwindigkeit des MMC-Moduls 
zu erhöhen, ist der Einsatz eines schnellen Zwischen- 
speichers. Dieser sogenannte Cache-Speicher setzt sich 
zusammen aus einem schnellen RAM-Speicher (Zyklus- 
zeit <100 ns), einem TAG-RAM und einer Cache-Steue- 
rung. Bei Lesezugriffen zum Systemspeicher überprüft 
die Cache-Steuerung, ob das Speicherwort bereits im 
schnellen Cache-RAM steht. Ist dieses nicht der Fall, 
wird das Wort aus dem Systemspeicher gelesen und 
gleichzeitig im Cache gespeichert. Benötigt der Mikro- 
prozessor erneut das Wort zu einem späteren Zeitpunkt, 
wird es aus dem schnellen Cache-RAM gelesen. Der 
Systembus wird nicht erneut belastet. Ein Schreibzyklus 
bewirkt das Speichern des Wortes im Cache-RAM. 
Danach schreibt die Steuerung das Wort selbsttätig in 
den Systemspeicher. 

Die Integration von Teilen der Betriebssystemsoftware 
auf den „On-Chip“-Speicher des Mikroprozessors, wie 
sie z. B. durch den „Makrostore“ der TMS-99000-Fami- 
lie [5] möglich wird, bewirkt bei gleichzeitiger Reduzie- 
rung der Systembusbelastung ebenfalls eine Erhöhung 
des Datendurchsatzes. Die enge Systembuskopplung 
bietet gegenüber der losen Kopplung folgende Vorteile: 


@ Einfache Erweiterung des Speichers oder der Ein-/Aus- 
gabe durch Standardmodule. 

© Zugriff zu allen passiven Modulen. 

© Einfache Realisierungredundanter Systeme oder Über- 
wachungsfunktionen. 

@ Freie Festlegung der Systemstruktur wie Multi-Master 
oder Master-Slave. 


2.2.1 Bussteuerung 


Ein Systembus wird durch die Bussteuerung multi- 
prozessorfähig. Die konfliktfreie Steuerung aller mögli- 
chen Bus-Master erfordert das Erkennen des Busstatus 
und Regeln für die Freigabe und die Übernahme der 
Buskontrolle durch einen Bus-Master. Liegen mehrere 
Zugriffsanordnungen vor, wird die Buszuteilung über 
festgelegte Prioritäten geregelt. Beim E-BUS wird die 
Bussteuerung synchron mit dem Bustakt vorgenommen. 

Mit der positiven Bustaktflanke (BUSCLK = Bus- 
Clock) erfolgt die Freigabe und Übernahme der Buskon- 
trolle durch einen Bus-Master. Der Belegtzustand des E- 
BUS ist durch eine bidirektionale Busleitung, genannt 
„BUS BUSY“ (BUSY-), gekennzeichnet. 

Ein Bus-Master meldet eine vorliegende Busanforde- 
rung durch Deaktivierung (Low-Pegel), der GRANT- 
OUT-Leitung. Das Signal „ACCESS GRANT IN“ (GRAN- 
TIN) des E-BUS dient zur Zuteilung des Buszugriffes 
(Bild 15). Für einen Bus-Master gilt folgende Regel für 
die Buszuteilung. 

— Eine vorliegende Busanforderung wird synchron mit 

BUSCLK- durch Setzen (Low-Pegel) der GRANTOUT- 
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Leitung an Bus-Master mit geringerer Priorität oder 

eine parallele Bussteuereinheit gemeldet. Mit jeder 

positiven BUCLK-Flanke wird eine Buszuteilung über 
die Signale „GRANTIN“ und „BUSY-“ durchgeführt. 
Die Busanforderung des Masters mit der höchsten 

Priorität wird durch einen High-Pegel auf der 

GRANTIN-Leitung quitiert. Ist der E-BUS frei (BUSY- 

auf High-Pegel), belegt der neue Bus-Master den Bus 

durch Aktivierung der BUSY- und Deaktivierung der 

GRANTOUT-Leitung. 

Bei einem Bustakt von max. 10 MHz beträgt die Bus- 
zuteilungszeit nur 100 ns. Der gegenwärtige Bus-Master 
unterliegt folgenden Regeln für die Freigabe des E-BUS: 
— Liegt keine interne Busanforderung mehr vor oder 

wird die Buszuteilung entzogen (Low-Pegel auf 

GRANTIN), so muß der gegenwärtige Bus-Master den 

E-BUS am Ende der laufenden Busoperation freigeben. 

Dies erfolgt durch Freigabe der BUSY-Leitung. Ist wei- 

terhin eine interne Busanforderung vorhanden, wird 

GRANTOUT synchron mit BUSCLK wieder auf Low- 

Pegel gesetzt und auf eine erneute Buszuteilung 

gewartet. Die Bussteuereinheit (Arbiter) des Bus- 

Master darf nur dann von der Freigaberegel abwei- 

chen, wenn vom Master ein BUSLOCK-Signal vorliegt. 

Dieses ist notwendig, um Systemflags (Semaphores) 

zu testen und zu setzen oder schnelle Blocktransfers 

durchzuführen. 

— Liegen zwei oder mehrere Busanforderungen für den 
E-BUS vor, so ist nach einem festgelegten Schema der 
Bus-Master mit der höchsten Priorität auszuwählen. 
Beim E-BUS ist sowohl die einfache serielle, wie auch 
die parallele Prioritätensteuerung vorgesehen. 


2.2.1.1 Serielle Prioritätensteuerung 


Bei der seriellen Prioritätensteuerung wird den Steck- 
plätzen eines Einbaurahmens eine feste Priorität zuge- 
wiesen. Die Verdrahtung der GRANT-Leitungen erfolgt 


dabei so, daß GRANTOUT des ersten Bus-Masters mit’ 


dem GRANTIN des nächsten verbunden ist. Dadurch 
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erhält der Bus-Master, dessen GRANTIN-Eingang 
andauernd auf High-Pegel liegt, die höchste Priorität 
innerhalb der seriellen Kette. Dieses unter dem Namen 
„Daisy-Chain“ bekannte Zuteilungsverfahren mit stati- 
scher Priorität zeichnet sich aus durch: 
— geringen Leitungsaufwand, 
— dezentrale Buszuteilung mit geringem Hardwareauf- 
wand, 
- schnelle Prioritätenfestlegung 
BUSCLK-Zyklus, 
— geringe Synchronisationsverluste. 
Als Nachteil des Daisy-Chains wird manchmal die stati- 
sche Priorität des einzelnen Steckplatzes empfunden. 
Diese statische Priorität hat zur Folge, daß im Falle einer 
Überlastung des Systembusses (die Summe der benötig- 
ten Buszeit übersteigt die Kapazität des Systembusses) 
dem Bus-Master mit der geringsten Priorität weniger 
Buszeit zugeteilt wird. Das heiß, der Datendurchsatz des 
Bus-Masters mit geringster Priorität wird so weit redu- 
ziert, bis der Systembus seine volle Kapazität erreicht 
hat. Für industrielle Anwendungen ist dies auch durch- 
aus notwendig, da bestimmte Aufgaben innerhalb einer 
maximalen Zeit auf jeden Fall abgearbeitet werden müs- 
sen. Grundsätzlich muß ein MMC-System natürlich so 
konzipiert werden, daß die zur Verfügung stehende 
Kapazität des Systembusses ausreicht. 


innerhalb eines 


2.2.1.2 Parallele Prioritätensteuerung 


Der E-BUS sieht für Anwendungsfälle, in denen eine 
dynamische Prioritätenzuweisung erfolgen soll, die 
parallele Buszuteilung vor. Die GRANTIN- und 
GRANTOUT-Leitung jedes einzelnen Bus-Masters wird 
dabei parallel auf einen speziellen Steckplatz geführt. 
Dieser spezielle Steckplatz dient zur Aufnahme eines 
sogenannten „Supervisor-Moduls“ (Bild 15). 

Am Supervisor-Modul liegen somit die Busanforde- 
rungen aller Master-Module parallel an, und die Priori- 
tätenfestlegung kann frei nach den gegebenen Anforde- 
rungen gewählt werden. Es läßt sich sowohl die einfache 
statische, die rotierende und die dynamische Prioritä- 
tenzuweisung einsetzen. Die Buszuteilungslogik (Bele- 
gung und Freigabe des E-BUS) der Master-Module ist 
weiterhin dezentralisiert. Lediglich die Prioritätensteue- 
rung wird auf dem Supervisor-Modul zentralisiert. 
Diese Zentralisierung ist bei der dynamischen Prioritä- 
tensteuerung unumgänglich, da sonst keine konfliktfreie 
Zuteilung gesichert ist. ‚ 


® Statische Prioritäten 


Die Buszuteilung nach statischen Prioritäten -ergibt, 
wie beim Daisy-Chain, für jeden Master-Modul eine 
feste Priorität der Busforderung. Eine direkte Zuordnung 
der Priorität zur Reihenfolge der Steckplätze ist nicht 
erforderlich. Bei einer großen Anzahl von Master-Modu- 
len muß anstelle des Daisy-Chains die parallele Prioritä- 


tensteuerung eingesetzt werden, da die Durchlaufverzö- 
gerungszeit der seriellen Kette zu groß wird, um inner- 
halb eines BUSCLK-Zyklus eine Buszuteilung sicher 
auszuführen. Die erforderliche Logik zur Prioritätenfest- 
legung ist einfach mit Standard-LPS-Bausteinen (z. B. 
Prioritätcodierer SN74LS348) zu realisieren. 


® Rotierende Prioritäten 


In Systemen mit mehreren gleichberechtigten Master- 
Modulen (z.B. Multi-User-DV-Anlagen) ist es wün- 
schernswert, jedem Master die gleiche Buszeit zur Verfü- 
gung ‚zu stellen. D.h., daß der Datendurchsatz aller 
Master-Module im Falle einer Systemüberbelastung 
annähernd gleichmäßig reduziert wird. Dieses wird oft 
als „faire Buszuteilung“ bezeichnet, da alle Master- 
Module einen „fairen“ Anteil der Systembuszeit erhal- 
ten [6]. Durch die sequentielle Änderung der Prioritäts- 
folge erhält dann jeder mögliche Bus-Master einmal 
innerhalb eines Zyklus die höchste Priorität. Bei vier 
Bus-Mastern z. B. erhält erst Master 1 die höchste Priori- 
tät, dann Master 2, 3, 4 und dann wieder Master 1. Die 
höchste Priorität wird also in einer Kette von einem zum 
nächst möglichen Bus-Master weitergereicht. Die Reali- 
sierung der rotierenden Prioritäten kann vollständig 
dezentralisiert werden [7, 8]. Nachteil bei der Dezentra- 
lisierung ist, daß entweder die Anzahl der Busleitungen 
[8] oder die Buszuteilungszeit [7] ansteigt. 


© Dynamische Prioritäten 


Soll die Buszuteilung sich ständig den ändernden 
Systembedingungen anpassen, so kann zu einer dynami- 
schen Prioritätenzuteilung übergewechselt werden. Ziel 
der dynamischen Zuteilung kann es z. B. sein, die Bus- 
anforderungen in der Reihenfolge ihres Auftretens zu 
bestätigen (FIFO-Prinzip). Alternativ kann auch eine 
programmierbare Prioritätsfolge oder eine Kombination 
aus festen Prioritäten und FIFO-Prinzip gewählt wer- 
den. Treten mehrere Busanforderungen gleichzeitig auf, 
erfolgt die Zuteilung wieder an Hand einer festen oder 
programmierbaren Sequenz. Die Unterschiede der drei 


möglichen Prioritätensteuerungen in der Buszuteilung 
zeigt Bild 16 am Beispiel eines Systems mit vier MMC- 
Modulen. Bei festen Prioritäten der Master (Priorität 1, 
2, 3 und 4) unterbricht jede Busanforderung mit höherer 
Priorität einen Master mit geringerer Priorität. Für den 
MMC-Modul 1 bedeutet dies, daß es den E-BUS immer 
mit minimaler Verzögerungszeit zugeteilt bekommt. Die 
Zuteilung nach rotierenden Prioritäten, mit der Sequenz 
1, 2, 3 und 4 hat zur Folge, daß jede Busanforderung so 
lange verzögert wird, bis der Master die höchste Priorität 
erhält. Die maximale Antwortzeit setzt sich aus der 
Summe der Buszeiten der anderen möglichen Bus- 
Master zusammen. 

Das FIFO-Prinzip der dynamischen Zuteilung wurde 
in Bild 18 vorausgesetzt. D. h., alle Busanforderungen 
werden in der Reihenfolge ihres Erscheinens beantwor- 
tet (1-2-4-3 usw.). Setzt man die Buszeiten der vier 
MMC-Module zu 100 % und vergleicht die drei Arten 
der Buszuteilung in Bild 16, so fällt auf, daß bei festen 
Prioritäten für den Master mit der höchsten Priorität 
definierte Zuteilungszeiten erreicht werden kann. 

Erkauft wird dieser Vorteil durch Verzögerung der 
Master mit geringerer Priorität. Ist die „Überlastung“ des 
Systembus nur kurzzeitig, sind die Unterschiede in der 
Buszuteilung nur in der Reihenfolge zu sehen. Die Bus- 
zuteilung nach statischen Prioritäten kann auch in einer 
Form erfolgen, welche einen blockorientierten Buszu- 
griff für jeden Bus-Master ermöglicht. Ein Master höhe- 
rer Priorität übernimmt die Buskontrolle erst, wenn der 
Buszugriff des gegenwärtigen Bus-Masters abgeschlos- 
sen ist. Die wesentlichen Vorteile der parallelen 
Busprioritätenzuteilung durch ein Supervisor-Modul 
sind die Möglichkeit der Überwachung und Steuerung 
der Busaktivitäten. Bus-Master können durch WATCH- 
DOG-Schaltungen [9, 10] überwacht und im Fehlerfall 
vom E-Bus getrennt werden. Weitere Vorteile der paral- 
lelen Prioritätensteuerung sind: 


— Schnelle Buszuteilung innerhalb eines BUSCLK-Zy- 
klus; 

— Freie Wahl der Prioritätenzuweisung (feste, rotierende 
oder dynamische Prioritätenzuweisung); 

-Einfache Testmöglichkeiten während der Entwick- 
lungs- und Betriebsphase des MMC-Systems. 





Bild 15. Parallele 
Prioritätensteuerung 
am E-BUS 
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Für die genannten Vorteile muß der Systementwickler 
den etwas höheren Hardware-Aufwand des Supervisor- 
Moduls in Kauf nehmen. Beim E-BUS sind für die paral- 
lele Prioritätensteuerung bis zu acht Bus-Master, vier 
DMA- und zwei Interrupt-Kanäle innerhalb eines 19- 
Zoll-Steckrahmens vorgesehen. 


3 Praktischer Einsatz der Systembuskopplung 


Die in einem Mikrocomputersystem verfügbare 
Rechenleistung kann oft schon durch den Einsatz eines 
weiteren MMC-Moduls entscheidend verbessert wer- 
den. Es ist dabei nicht unbedingt notwendig, komplexe 
Multi-Mikrocomputerstrukturen aufzubauen, wenn die 
Teilung der Systemfunktion auf ein Doppel-Prozessor- 
system ausreicht. Dieses ist der Fall wenn: 

— Zeitprobleme nur bei einer bestimmten Funktion vor- 
liegen, oder 

— einfache Ausfallüberwachung gewünscht wird, oder 

- die Teilung der Systemfunktion für die Softwareerstel- 
lung günstig wird. 


Als Beispiel soll hier kurz ein Doppel-Prozessorsystem 
beschrieben werden, auf welches alle genannten Punkte 
zutreffen. Die Baugruppe des Systems besitzt ein uC- 
Modul, das vorwiegend in BASIC programmiert wird. 
Außerdem beinhaltet es ein an den E-BUS eng gekoppel- 
tes MMC-Modul. Die zeitkritischen Operationen (z. B.) 
dreidimensionale Bahnberechnungen) werden in 
Assembler programmiert und das Programm ist vorwie- 
gend im lokalen EPROM-Bereich des MMC-Moduls 
gespeichert. Der Assembler-Rechner bedient alle zeit- 


kritschen Ein-/Ausgabeoperationen und erhält seine 
Steuerparameter vom BASIC-Rechner. Der Datenaus- 
tausch läuft über das gemeinsame Speichermodul am E- 
BUS, welches auch das BASIC-Anwenderprogramm auf- 
nimmt. Die Belastung des Systembus durch den BASIC- 
Rechner ist nach vorliegenden Erfahrungen kleiner als 
10 %, da sich der BASIC-Interpreter im lokalen Speicher 
befindet. Dadurch steht dem Assembler-Rechner mehr 
als genügend Buszeit zur Verfügung für die Ausführung 
umfangreicher Ein-/Ausgabeoperationen. 

Eine zusätzliche Steigerung der Systemleistung durch 
Hinzufügen weiterer BASIC- oder Assembler-Rechner 
ist möglich. 
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Ein modulares, hierarchisch strukturiertes 
Multi-Mikrocomputer-System 


Bei der klassischen Rechnerstruktur läßt sich der 
Durchsatz nicht beliebig steigern. Zur Lösung dieses 
Problems bieten sich Multi-Mikrocomputer-Systeme 
an. Hier strebt man als Idealfall an, daß die Summe der 
Einzeldurchsätze gleich dem Gesamtdurchsatz ist. 


1 Systemkonzept 


Die Rechnerkonzeption entspricht einem modularen, 
(baumförmig) strukturierten Multi-Mikrocomputer- 
System (Bild 1). Das System ist in die Gruppe der 
Computer einzuordnen, die man unter der Bezeichnung 
„Multiple Instruction Stream/Multiple Data Stream“ 
zusammenfaßt. Als GPU eignen sich die Mikroprozesso- 
ten TMS9900, TMS9980/81 und TMS9940 [8, 9, 10]. 
Jeder Mikrocomputer verfügt über private Speicher und 
hat keinen direkten Zugriff zum Speicher eines anderen 
(Bild 2, [7). Es sind keine konkurrierenden Zugriffe auf 
gemeinsame Betriebsmittel (Bus, Speicher) erforderlich, 
Verklemmungssituationen (Deadlocks) können somit 
vermieden werden. Dieses Konzept ist besonders bei 
steigender MC-Zahl vorteilhaft, da sich im allgemeinen 
ein allen Mikrocomputern gemeinsames Betriebsmittel 
als Flaschenhals erweist. 

Bei der Systemauslegung gilt es, den zu bearbeitenden 
Gesamtprozeß mit einer Top-Down-Strategie in sinn- 
volle Teilprozesse zu zerlegen und diese in verschiede- 
nen Betriebsmitteln weitgehend autonom zu realisieren. 
Die Aufgabenteilung führt zu einer Parallelisierung der 
Teilprozesse und zu einem praktisch beliebig steigerba- 
ren Durchsatz des Gesamtsystems. Daneben sollte bei 
der Zerlegung in Teilprozesse auf einen möglichst gerin- 
gen Datenverkehr zwischen den einzelnen Einheiten 
geachtet werden. Datenreduktion an geeigneter Stelle 
und, soweit machbar, lediglich die Integration von Teil- 
ergebnissen in der übergeordneten Hierarchie-Ebene 
sind hierzu Lösungsansätze. Des weiteren können 
bereits untergeordnete uC-Stationen über Schnittstellen 
zur „Umwelt“ verfügen, um den Datenfluß innerhalb 
des Gesamtsystems zu minimieren. Die feste Zuordnung 
der Teilprozesse zu den einzelnen Mikrocomputern 
führt zu einem relativ einfachen Betriebsystem, geringe- 


Inwieweit man das erreicht, hängt im wesentlichen von 
der Art und Anzahl der gemeinsamen Betriebsmittel 
(Bus, Speicher) ab. Dieser Gesichtspunkt wurde beim 
nachfolgend beschriebenen System besonders be- 
rücksichtigt. 


rem Schnittstellenaufwand und zu größerer Transpa- 
renz, als dies bei wahlfreier Zuordnung möglich wäre. In 
allgemeiner Anwendung ist durch den modularen Auf- 
bau eine optimale Anpassung an die problemspezifi- 
schen Erfordernisse gewährleistet. 

Die hierarchische Struktur nach dem Master-Slave- 
Prinzip ergibt sich aus bestimmten Interrupt-Fähigkei- 
ten der untergeordneten uC-Stationen. Die Slave-Station 
kann von Seiten des Masters zu einer um wenige us 
Reaktionszeit verzögerten Kontaktaufnahme veranlaßt 








Bild 1. Das baumförmig strukturierte Multi-Mikrocomputer- 
System 
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werden (Interrupt Context Switch bei TMS9900 ca. 7 us). 
Die Slave-Station ihrerseits signalisiert über ein defi- 
niertes Request-Bit die Bereitschaft zur Kommunikation. 
Dieser Anforderung muß nicht zwingend von Seiten des 
Masters in einer bestimmten Zeit nachgekommen wer- 
den. Somit ergibt sich, bezüglich der Reaktionszeit, eine 
relativ enge Kopplung in der Hierarchie von oben nach 
unten und eine lose Kopplung von unten nach oben. 


2 Kommunikation zwischen den uCs 


Über eine rechnerspezifische CRU (Communication 
Register Unit, 1 2]) wird nach der Handshaking-Methode 
die Kommunikation eingeleitet, unterhalten und been- 
det (Bild 3). Über diese Schnittstelle werden in Richtung 
Slave Befehle und Daten und in Richtung Master Status- 
meldungen und Daten gesendet. 


Befehle und Statusmeldungen sind bitweise codiert. 
Sie werden mit SBO-/SBZ-Befehlen (Set Bit to One, Set 
Bit to Zero) in einem uC generiert und per TB-Befehl 
(Test Bit) im anderen abgefragt. 

Die Daten-Ports werden mit den Mehrbitbefehlen 
LDCR (Load Communication Register) und STCR (Store 
Communication Register) geladen bzw. gelesen. Wegen 
des bitseriellen Übertragungsmodus an der CRU- 
Schnittstelle werden für die uC/uC-Schnittstelle ledig- 
lich die CRU-Steuersignale CRUCLK, CRUOUT, CRUIN 
sowie eine, von der Breite der Daten-Ports und des 
Befehls-/Status-Vorrats abhängige Anzahl an Adreßlei- 
tungen benötigt. Es ist also nicht erforderlich, den 
Datenbus oder den kompletten Adreßbus der Mikrocom- 
puter zur gemeinsamen Schnittstelle herauszuführen. 
Dies hat neben der geringeren Zahl benötigter Leitungen 
und zugehöriger Signalpuffer eine Erhöhung der Störsi- 
cherheit zur Folge. 





zu weiteren „C-Stationen 
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Netz-Reset 


Bild 2. Blockschaltung einer Slave-Einheit 
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Bild 4. Ablauf einer durch Interrupt eingeleiteten Datenübertra- 
gung; TFX und TFY zeigen den Gültigkeitsbereich von Befehlen/ 
Status und Daten an 
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Bild 3. Interface zwischen korre- Slave/Master 
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Bild 5. Aufbau der übertragenen Information; die 
Satz-Nr. bestimmt die Datenart 
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Die Datenübertragungsrate einschließlich der die 
Übertragung vorbereitenden und abschließenden 
Befehlsausgaben und Statusmeldungen liegt bei 70 kBd. 
Falls erforderlich, kann mit einer Verbreiterung der 
Daten-Ports auf 16 Bit, unter Verwendung der vorliegen- 
den Prozeduren, die Übertragungsrate auf etwa 110 kBd 
gesteigert werden. 

Wird von Seiten des Masters eine Kommunikation 
gewünscht, erfolgt der Anstoß hierzu per Interrupt: Der 
Master setzt ein Interface-Bit (IR), das im Slave auf einen 
Interrupt-Eingang des TMS9901 11] geführt ist. Die 
erfolgte Reaktion zeigt der Slave mit einem Interrupt- 
Acknöwledge-Bit an. Der Slave seinerseits meldet sich 
über.ein Request-Bit (REQ). Dieses Bit wird im Polling- 
Mode vom Master abgefragt und, abhängig vom aktuel- 
len Betriebszustand, erfolgt eine entsprechende Reak- 
tion des Masters. 


3 Software 


Der Software-Anteil ist, vornehmlich mit zunehmen- 
der Komplexität des auszuführenden Gesamtprozesses, 
im Entwicklungsaufwand deutlich höher anzusetzen als 
die Hardware-Komponente. Das Bindeglied zwischen 
Hardware und Software stellen die Übertragungsproze- 
duren dar (Bild 4). „Time-out“-Kriterien überwachen 
den Ablauf der Prozeduren und können im Fehlerfall zu 
einer Wiederholung bzw. bei Häufung der Übertragungs- 
fehler zu Fehlermeldungen und zum Aufruf eines 
Selbsttestprogramms führen. 

Auf diese Weise kann durch Ausnutzung der verteil- 
ten Intelligenz, ohne zusätzlichen Hardware-Aufwand 
(Speicherbedarf für das Testprogramm vernachlässigt) 
und unter der Voraussetzung, daß die höchste uC-Sta- 
tion fehlerfrei ist, eine defekte uC-Station bzw. Übertra- 
gungsstrecke erkannt werden. Diese Voraussetzung ent- 
fällt, wenn auf der obersten uC-Station ein Ersatz-Mikro- 
computer als „kalte Reserve“ installiert ist. Dieser tritt, 
in Verbindung mit einer m-aus-n-Entscheidungslogik 
der untergeordneten Mikrocomputer, im Fehlerfall an 
die Stelle der defekten Einheit. Der Aufwand steigt 
jedoch erheblich und ist in der Regel nur in Systemen 
mit hoher Gesamtverfügbarkeitsforderung (Reaktortech- 
nik, Prozeßautomatisierung usw.) zu vertreten. 

Der Informationsfluß zwischen korrespondierenden 
Mikrocomputern erfolgt von Speicher zu Speicher, byte- 
seriell als Blocktransfer mit einem in der Länge varia- 
blen Datenfeld. Nach der Synchronisierung wird von 
Seiten der übergeordneten Station zunächst ein Steuer- 
block gesendet. Er beinhaltet die Adresse des selektier- 
ten Slaves (redundant zum Select-Bit), eine Record-Nr., 
welche die Art des codetransparenten Datenfeldes 
bestimmt, einen Parameter für die Länge des Datenfel- 
des und ein Sicherungsfeld. Das Sicherungsfeld wird 
nach einem CRC-Verfahren gebildet und sichert den 
Steuerblock ab (Bild 5). Mit einer Statusmeldung zeigt 
der Slave, ob er die vom Master im Steuerblock angege- 
benen Informationen senden oder empfangen kann. 
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Nach entsprechender Statusmeldung erfolgt der eigent- 
liche Datentransport. Die Übertragungsrichtung ist hier- 
bei generell aus der Sicht der jeweils übergeordneten 
Station festgelegt. Abgeschlossen wird die Datenübertra- 
gung mit einem Abschlußbefehl (EOT) des Masters und 
einer Statusmeldung des Slaves. Bild 6 zeigt als Beispiel 
eine Datenausgabe. 


3.1 Befehle 


Befehle werden von der Master-Station gesendet und 
von der Slave-Station mit einer Statusmeldung beant- 
wortet. Durch die Art der in der Slave-Station erzielten 
Reaktionen, kann man unterscheiden zwischen Befeh- 
len, die einen Informationsfluß zwischen Master und 
Slave bewirken und solchen, die den Slave veranlassen, 
seinerseits ihm untergeordnete Mikrocomputer und/ 
oder Schnittstellen anzusprechen. Zur letztgenannten 
Gruppe zählen auch die vom Anwender problemspezi- 
fisch zu definierenden Befehle, die zur eventuellen 
Erweiterung des Befehlsvorrats (Tabelle 1) zur Verfü- 
gung stehen. 

Statusmeldungen geben der übergeordneten Station 
Aufschluß über den aktuellen Betriebszustand der selek- 
tierten, untergeordneten Station. Sie können neben dem 


Tabelle 1. Befehlsvorrat 


NOP Slave schickt Statusmeldung 

No Operation 

DINP Master leitet eine Dateneingabe ein 
Data Input 

DOUT Master leitet eine Datenausgabe ein 
Data Output 

EOT Master schließt eine fehlerfreie Daten- 
End of Transfer übertragung ab 

TERR Master beendet eine fehlerhafte Daten- 
Transfer Error übertragung 

CLRST Veranlaßt den Slave, seine Statusbits in 
Clear Status einen def. Grundzustand zu versetzen 
RES Versetzt den Slave in einen Anfangszustand 
Reset 


Tabelle 2. Statusinformationen 


CREQ Slave erwartet einen Befehl 

Command Request 

DREQ Slave ist zur Datenübertragung bereit 
Data Request (nach DINP oder DOUT) 

DFLG Slave fordert Beendigung der Datenüber- 
Data Flag tragung nach einem Fehler an 

ATT Slave weist auf eine Hastsituation hin 
Attention 

JMP Slave fordert den Master zu einer 

Jump Programmverzweigung auf 
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„normalen“ Zustand auch bestimmte Hastsituationen (z. 
B. Puffer voll) oder Fehlerzustände aufzeigen. Freie 
CRU-Ausgabe-Ports bieten dem Anwender darüber hin- 
aus die Möglichkeit, den vorhandenen Statusvorrat pro- 
blemspezifisch zu erweitern. Diese Statusinformationen 
(Tabelle 2) sind nicht zu verwechseln mit den prozes- 
soreigenen Statusbits. 


4 Anwendung 


Ein Multi-Mikrocomputer-System erscheint dann 
angezeigt, wenn die Erfordernisse eines Gesamtprozes- 
ses die Rechenleistung einer einzelnen CPU übersteigen 
oder in dessen Grenzbereich liegen. Dies kann beson- 
ders in rechenintensiven Gebieten wie numerischer 
Mathematik, Simulationstechnik Prozeßautomatisie- 
rung und Mustererkennung, die mit hohen Echtzeitfor- 
derungen verknüpft sind, der Fall sein. Multi-Mikro- 
computer-Systeme dringen hier, je nach Ausbaustufe, in 
den Leistungsbereich von Minicomputern und Groß- 
rechenanlagen vor. Zukünftig wird ein Hauptaugenmerk 
auf die Entwicklung „verteilter Betriebssysteme“ zu 
richten sein. Unter Beachtung von Auf- und Abwiärts- 
kompatibilität der Einzelkomponenten sowie der Soft- 
ware-Portabilität bieten Multi-Mikrocomputer-Systeme 
eine wirtschaftliche Lösung der genannten Problemstel- 
lungen. 


Literatur 


> 


[1] Faggin, F.: VLSI verändert Computer-Strukturen. ELEKTRONIK 1978, H. 12, 
8.57.61. “ 

[2] Raphael, A.: Mehrfachverarbeitung mit Multiprozessorsystemen. ELEK- 
TRONIK 1978, H. 11, S. 84...87. 

[3] Bode, A.: Bit-Slice-Architekturen: Auswirkung des Mangels an Kommuni- 
kationswegen auf die Struktur von Mikroprozessoren NIE 62, Fachta- 
gungsbericht. o- 

[4] Feissel, W.: Der Einfluß eines Pufferspeichers auf die Operationsgesehwin- 
digkeit kommerzieller DV-Anlagen. GI-NTG, Fachtagungsbericht,, 1974: 
Struktur und Betrieb von Rechensystemen. a) 

[5] Lehner, M., Horneber, E.-H.: Strukturiertes Multimiktoprozessor-System 

SMS 201. Siemens Forsch.- u. Entwicklungsb. 1980/2, Bd. 9, S. 88...93. 

[6] Kudielka, V.: Parallelverarbeitung und modularer Systemaufbau, GI-NTG, 

Fachtagungsbericht 1974: Struktur und Befrieb von Rechensystemen. 

[7] Schmidt, B.: Betriebssystenistruktur für eine Mehrprozessorkonfiguration 

mit privaten Speichern. NTG 62, Fachtagungsbericht. 

[8] TMS 9900 Microprocessor Data Manual. Texas Instruments. ö 
[9] TMS 9981 Microprocessor Data Manual. Texas Instruments. 

[10] TMS 9940 Microprocessor Data Manual. Texas Instruments. 

[11] TMS 9901 Programmable System Interface. Texas Instruments. 

[12] Höger, W., Tinul, W.: Meßwertverarbeitung mit einem Mikrorechner. ELEK- 

TRONIK 1980, H. 6, S. 61...64. 








Prof. Dipl.-Ing. Günter Schmitt 
Dr. rer. nat. Wolf Dieter Weiß 


Universelles Bussystem für 
verschiedene Mikroprozessortypen 


In den Anfängen der Mikrocomputertechnik wurde die 
Software ausschließlich für den Mikroprozessor 
geschrieben, der in der zu entwickelnden Schaltung 
vorhanden ist. Mit der Einführung immer leistungsfä- 
higerer Prozessoren entstand das Problem der Über- 
tragbarkeit bestehender Programme auf neue 
Systeme, das sich auch durch den Einsatz problem- 
orientierter Sprachen und „universeller“ Cross-Ent- 
wicklungssysteme nicht befriedigend lösen läßt. 

Bestehen zum Beispiel für ein größeres Entwicklungs- 


1 Aufgabenstellung 


An ein universelles Bussystem werden folgende 
Anforderungen gestellt: 

— Betrieb mit unterschiedlichen Prozessoren wie z.B. 
der 8080- und der 6800-Familie; 

- Betrieb mit Prozessoren unterschiedlicher Bitbreite 
wie z. B. mit den Standard-8-Bit-Prozessoren und den 
neuen 16-Bit-Prozessoren; 

—- Multiprozessorfähigkeit mit software- und hardware- 
gesteuerter Busübergabe; 

- auch für 8-Bit-Prozessoren Speichererweiterung über 
die Adressierungsfähigkeit von 64 KByte hinaus; 

-die Speicher- und Peripheriekarten müssen ohne 
Umschaltung für alle Prozessortypen verwendbar sein; 

— das Bussystem muß sowohl für Entwicklungen als 
auch für Anwendungen einsetzbar sein. 

Bei einem solchen universellen Bussystem kann jeder 
der Prozessoren einzeln oder gemeinsam mit anderen 
sowohl mit den Speichern als auch mit der Peripherie 
und den Massenspeichern zusammenarbeiten. Daher ist 
es möglich, das System in der Entwicklungsphase mit 
verschiedenen Betriebssystemen zu betreiben und in der 
Anwendungsphase Programme verschiedener Prozes- 
sortypen miteinander zu mischen. Die Entwicklungs- 
Hilfsmittel wie Massenspeicher und Interface-Schaltun- 
gen für Drucker und EPROM-Programmiergerät sind für 
jeden Prozessor verwendbar. Dies ermöglicht eine einfa- 
che Umrüstung des Systems auf neue Prozessortypen. 
Nach der Entwicklungsphase werden die Entwicklungs- 


projekt bereits Teilprogramme jedoch verschiedener 
Prozessoren oder können Softwarepakete anderer 
Prozessorfamilien fertig erworben werden, so bleibt 
nur eine Lösung, nämlich verschiedene Prozessoren 
in einem System mit gemeinsamen Speicher- und Peri- 
pheriebereichen laufen zu lassen. Die vorliegende 
Arbeit beschreibt ein Bussystem, das mit unterschied- 
lichen Prozessortypen betrieben werden kann und das 
darüber hinaus sowohl in der Entwicklungs- als auch 
in der Anwendungsphase verwendbar ist. 


hilfsmittel (Monitorkarte, Massenspeicher) entfernt und 
das System dient dann als Anwendungs-Computer. 


2 Zeitliche Steuerung 


Unter Bus-Timing wird hier die zeitliche Steuerung 
der Datenübergabe zwischen Prozessor und Speicher 








Bild 1. Steuerleitungen für das Bus-Timing 
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bzw. Peripherie verstanden. Die Prozessoren der 8080- 
Familie haben getrennte Steuerleitungen für Lesen und 
Schreiben und wickeln einen Speicherzyklus in mehre- 
ren Taktperioden ab. Die Peripheriebausteine können 
wahlweise wie Speicherbausteine oder auch getrennt 
angesprochen werden. Die Prozessoren der 6800-Fami- 
lie haben eine gemeinsame Steuerleitung für Lesen und 
Schreiben sowie z. T. ein Sondersignal für gültige Spei- 
cheradressen (VMA) und benötigen einen Takt für einen 
Speicherzugriff. Die Peripherieadressen werden wie 
Speicheradressen behandelt. 

Der 16-Bit-Prozessor 68000 kennt sowohl den asyn- 
chronen Speicher- als auch den synchronen Peripherie- 
zugriff. 

Bild 1 zeigt die Steuerleitungen für ein universelles 
Bussystem, das über Anpassungsschaltungen auf den 
jeweiligen Prozessorkarten den Speicher- und Periphe- 
riekarten Steuersignale für die Datenübergabe zuführt. 
Diese entsprechen dem Verhalten der 6800-Prozessorfa- 
milie. Die Leitung „PERDIS“ dient als Synchronisations- 
anzeige beim Übergang vom asynchronen in den syn- 
chronen Betrieb. 


3 Die Adressierung 


Ein modernes und zukunftsorientiertes Bussystem 
muß sowohl für 8 Bit als auch für die neuen 16-Bit- 





Peripherie 





MAIER WE 


a Schalter 


PER 





Bild 2. Steuerung der Peripherie 
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Prozessoren ausgelegt sein. Das setzt einen 16-Bit-Daten- 
bus und Adressierungsmöglichkeit über die 64 KByte 
der 8-Bit-Prozessoren voraus. 


3.1 Die Peripherie-Steuerung 


Die Peripherie wie z.B. Parallelschnittstellen oder 
Analog/Digital-Umsetzer benötigt nur einen relativ klei- 
nen Adreßbereich im Vergleich zu den Speichern. Aus 
diesem Grund enthält das vorgestellte Bussystem eine 
Peripherie-Auswahlleitung. Ein Decoder-PROM auf den 
Prozessor-Karten legt die Adresse des Peripherieberei- 
ches fest. Bild 2 zeigt die Peripherieauswahlleitung 
„PER“, die zur Auswahl der Peripheriekarten dient. 


3.2 Speichererweiterung über 64 KByte hinaus 


Folgende Gründe sprechen für eine Speichererweite- 
rung: 

— Moderne Betriebssysteme benötigen bereits annä- 
hernd 60 KByte, so daß dem Benutzer bei einem 64-K- 
System nur noch 4 KByte zur Verfügung ständen. 

— Bei der Zusammenarbeit mit 16-Bit-Prozessoren müs- 
sen auch die 8-Bit-Prozessoren auf den erweiterten 
Adreßbereich dieser Prozessoren zugreifen können. 

—Durch die erweiterte Speicherkapazität reduzieren 
sich die Zugriffe auf die Massenspeicher. Damit erhöht 
sich die Verarbeitungsgeschwindigkeit. 

— Bei Betriebssystemen, die den Multi-User-Betrieb 
unterstützen, muß jedem Benutzer ein ausreichender 
Arbeitsspeicher zugewiesen werden. 

— Grafikfähige Video-Umlaufspeicher benötigen eine 
große Arbeitskapazität und müssen sowohl von der 
Videosteuerung als auch vom System angesprochen 
werden können. 

Bild 3 zeigt den Aufbau des Speicherbereiches aus 
max. 8 Blöcken zu je 64 KByte. Zu den 16 Adreßleitun- 
gen treten acht Blockauswahlleitungen, die von einer 
Block-Kontrollkarte gesteuert werden. Bei 16-Bit-Pro- 
zessoren bilden die unteren 16 Adreßleitungen den 
eigentlichen Adreßbus, während die oberen Leitungen 
zur Blockauswahl benutzt werden. Bei einem System 
mit Karten im Europaformat ist ein zentraler Decodierer 
trotz der acht Busleitungen aus Platzgründen günstiger 
als eine dezentrale Decodierung, die mit nur drei Leitun- 
gen auskäme. . 


3.3 Gemeinsamer Speicher bei 8/16-Bit-Systemen ‘; 


Der Betrieb eines Prozessors allein oder mit einem 
anderen gleicher Bitbreite ist einfach. Die 8-Bit-Prozes- 
soren arbeiten auf einen 8-Bit-Datenbus mit byteorgani- 
sierten Speicher- und Peripheriekarten. Die 16-Bit-Pro- 
zessoren arbeiten auf zwei 8-Bit-Datenbusse. Dabei 
erhebt sich die Frage, ob für 16-Bit-Systeme besondere 
Karten eingesetzt werden müssen oder ob mit den Kar- 
ten der 8-Bit-Systeme gearbeitet werden kann. 


Bild 4 zeigt eine Lösung, die universelle Speicher- 
und Peripheriekarten verwendet, mit denen sowohl Ein- 
zelbetrieb von Prozessoren einer Bitbreite als auch 
gemischter Betrieb von Prozessoren verschiedener Bit- 
breite möglich ist. 

Die gezeigten RAM-Karten sind byteorganisiert; bei 
16-Bit-Systemen wird eine Karte über Brücken auf den 
unteren und eine zweite auf den oberen Datenbus gelegt. 
Die EPROM-Kärten werden über eine Kartensteuerung 
so umgeschaltet, daß sie sowohl auf den oberen als auch 
auf den unteren Datenbus als auch auf beide gleichzeitig 
arbeiten können. Die Peripheriekarten sind über Brük- 
ken ümschaltbar, werden aber vorzugsweise über den 
unteren Datenbus betrieben. Die Steuerleitungen „UDS“ 
und „LDS‘“ steuern den oberen bzw. den unteren Daten- 
bus. Sie sind bidirektional. Eine „WORD“ genannte 
Steuerleitung teilt den Speicher- und Peripheriekarten 
mit, ob ein 8-Bit-Prozessor oder ein 16-Bit-Prozessor 
Daten überträgt. Bei einem gemischten 8-Bit-/16-Bit- 
Betrieb muß der 8-Bit-Prozessor auf Daten zugreifen 
können, die im Bereich des oberen Datenbus liegen. Die 
8-Bit-Prozessorkarte legt also die WORD-Leitung kon- 
stant auf HIGH, und in diesem Fall erzeugen die Karten- 
steuerungen der Speicher die Steuersignale „UDS‘“ und 
„LDS“. Will z. B. eine Karte Daten aus dem Datenbereich 
übertragen, der am oberen Datenbus liegt, so bildet sie 


das Steuersignal „UDS“, damit die Prozessorkarte die 
Daten auf dem oberen Datenweg annehmen kann. Kar- 
ten mit 16-Bit-Prozessoren legen dagegen die WORD- 
Leitung konstant auf Low und erzeugen die Signale 
„UDS“ und „LDS“ selbst. 

Die beiden RAM-Bausteine des Bildes 4 zeigen die 
Adreßverschiebung zwischen einem 8-Bit- und einem 
16-Bit-Datenzugriff. Das Problem der unterschiedlichen 
Datenformate läßt sich leicht softwaremäßig lösen. 


4 Die Busvergabe 


Die Standardverfahren zum Auffrischen dynamischer 
Speicher und die Datenübertragung mit direktem Daten- 
zugriff (DMA) sollen hier nicht weiter betrachtet wer- 
den. Bei der Parallelarbeit mehrerer Prozessoren muß 
sichergestellt werden, daß immer nur ein Prozessor die 
Kontrolle über den Adreßbus, Datenbus und die Steuer- 
leitungen hat und daß sich alle anderen im Wartezu- 
stand befinden. 

Bild 5 zeigt eine Schaltung zur Busvergabe, die auf 
den Prozessorkarten angeordnet ist. Ein Flipflop (,Ser- 
vice-Request“) speichert den Zustand des Prozessors 
(Prozessor aktiv/Prozessor wartet). Es kann über eine 
bestimmte Adresse und ein bestimmtes Datenbit über 
den Datenbus gesetzt und rückgesetzt werden. 
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Über Brücken lassen sich verschiedene Betriebsarten 
einstellen. Brücke I legt fest, ob sich der Prozessor an der 
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Busvergabe beteiligt oder nicht. Brücke II ordnet dem 
Flipflop und damit der Karte ein Bit des Datenbus zu. 
Über dieses Bit kann das Flipflop gesetzt (Prozessor 
aktiv) oder rückgesetzt werden (Prozessor wartet). Damit 
können bei einem 8-Bit-Datenbus maximal acht Prozes- 
soren parallel arbeiten. Die Prozessoren werden also 
über Befehle, die alle auf einer gemeinsamen Adresse 
liegenden Flipflops ansprechen, an den Bus geschal- 
tet bzw. abgeschaltet. Brücke III legt fest, ob der Prozes- 
sor nach einem Reset die Kontrolle erhält oder nicht. 
Brücke IV dient zusammen mit den Steuereingängen 
„BUSRQIN“ und „BUSRQOUT“ zur Vergabe einer Prio- 
rität. . 


Der „neue“ Prozessor kann den Bus nur dann über- 
nehmen, wenn der „alte“ seinen letzten Befehl vollstän- 
dig ausgeführt und den Bus freigegeben hat. Dies wird 
über die Leitung „BUSY“ signalisiert. Hat der „neue“ 
Prozessor den Bus übernommen, so setzt er seinerseits 
die BUSY-Leitung aktiv. e. 


Die Busvergabe kann nach dem Master-Verfahren, der 


Prioritätskette und der zentralen Verteilung erfolgen. 


4.1 Das Master-Verfahren 


Bei diesem Verfahren sind alle Prozessoren gleichbe- 
rechtigt; jedoch muß durch Einstellen der Brücken dafür 


gesorgt werden, daß bei einem Reset zunächst ein Pro- 
Zessor die Kontrolle übernimmt. Dieser bestimmt durch 
Umschalten der Flipflops seinen Nachfolger. Die Bus- 
vergabe kann durch ein Betriebssystem nach verschiede- 
nen Gesichtspunkten vorgenommen werden. 


I 


4.2.Die Prioritätskette 


Bei der Prioritätskette („Daisy Chain“) nach Bild 6 legt 
die räumliche Anordnung der Prozessorkarten im Ein- 
schub eine Priorität innerhalb der Prozessoren fest. 

Die Anschlüsse BUSRQIN und BUSRQOUT bilden 
auf dem Bus eine Leitung, die 
an jedem Steckplatz aufgetrennt 


5 Beispiel einer Busübergabe 


Bild 7 zeigt als Anwendungsbeispiel eine Busüber- 
gabe zwischen dem 16-Bit-Prozessor 68000 und dem 
8-Bit-Prozessor 6809. 

Mit einem 68000-Entwicklungssystem bestehend aus 
einer Prozessor-Karte und einer Monitor-Karte ist ein 
Treiberprogramm für einen Analog/Digital-Umsetzer zu 
entwickeln. Nach einem Reset arbeitet zunächst das 
68000-System. Die Editierung und Übersetzung des 
Treiberprogramms wird mit einem Editor und Cross- 
Assembler eines 6809-Systems vorgenommen. Für diese 
Entwicklungsphase gibt also das 68000-System die Kon- 





ist. Liegt der BUSRQIN-Eingang 
einer Karte auf Low, so hat sie 
zur Zeit die höchste Priorität 
und kann die Buskontrolle über- 
nehmen. Liegt der Eingang auf 
High, so kann sie die Kontrolle 
nicht übernehmen oder muß sie 
abgeben. Eine Karte, die die 
Buskontrolle übernommen hat 
oder übernehmen will, legt ih- 
ren BUSRQOUT-Ausgang auf 
High und sperrt damit alle da- 
hinter liegenden Karten der Ket- 
te. Der BUSRQIN-Eingang der 
Karte mit der höchsten Priorität 
wird mit einer Brücke auf Low 


BUSRQIN 


BUSRQOUT 





BUSROIN BUSRQOUT BUSROIN BUSROOUT 


@ 
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gelegt. Die Busvergabe kann wie 
unter Punkt 4.1 softwaremäßig 
durch ein Betriebssystem erfol- 
gen, jedoch kann jetzt jede Karte 
entsprechend ihrer Priorität in 
die Busvergabe aktiv eingreifen. 


4.3 Die zentrale Busvergabe 


Trennt man die BUSRQIN/ 
BUSRQOUT-Leitungen des Bil- 
des 6 am Bus auf und führt die 
Anschlüsse getrennt einer Bus- 
Steuerkarte (Arbitrator) zu, so 
kann diese die Busvergabe zen- 
tral steuern. Jede Karte kann da- 
bei Anforderungen über das Ser- 
vice-Request-Flipflop und die 
BUSRQOUT-Leitung absetzen; 
die Vergabe erfolgt jedoch vom 
Arbitrator über den BUSRQIN- 
Eingang. Der Arbitrator kann so- 
wohl softwaremäßig mit einem 
eigenen Prozessor als auch mit 
schnellen Schaltungen hard- 
waremäßig aufgebaut sein. 


Prozessorkarte 3 
niedrigste Priorität 


Prozessorkarte 1 Prozessorkarte 2 


hochste Prioritat 
Bild 6. Bussteuerung mit einer Prioritätskette 
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trolle an das 6809-System ab, das das fertige Maschinen- 
programm im Format des 68000-Prozessors in den 
Arbeitsspeicher lädt und die Kontrolle wieder zurück- 
gibt. Der Test des Programms erfolgt mit dem 68000- 
Entwicklungssystem. 


6 Einsatzmöglichkeiten 


Das vorliegende System besteht aus einem 96poligen 
Bussystem (MAKBUS) mit aufeinander abgestimmten 
Prozessor-, Betriebssystem-, Speicher-, Peripherie- und 
Geräteinterfacekarten im Europaformat. Infolge seiner 
Fähigkeit, verschiedene Prozessoren an einem Bus zu 
betreiben, ergeben sich folgende besondere Einsatzmög- 
lichkeiten: 

— Bei einem Übergang von einem 8-Bit- zu einem 16-Bit- 
System kann bestehende 8-Bit-Software verwendet 
werden. 

- Bei einem Übergang von einer Prozessorfamilie zu 
einer anderen können ebenfalls bestehende Pro- 
gramme verwendet werden. 

—Bei einem Wechsel von einer Prozessorfamilie zu 
anderen können die Peripherie- und Speicherkarten 
weiter benutzt werden. Damit vereinfacht sich die 
Lagerhaltung. 

— Das System läßt sich leicht an Betriebssysteme anpas- 


sen, die in zunehmendem Maße von reinen Software- 

häusern angeboten werden. 

— Da die Peripherie- und Speicherkarten für alle Prozes- 
soren verwendbar sind, ist es nunmehr möglich, den 
für jede Anwendung günstigsten Prozessortyp einzu- 
setzen, ohne nun an einen bestimmten Hersteller und 
dessen „Familie“ gebunden zu sein. 

Das vorliegende universelle Bussystem zeigt einen 
möglichen Ausweg aus der Softwarekrise, denn bisher 
mußte die Software für bestehende Hardware entwickelt 
werden; nun ist es möglich, die Hardware an die Soft- 
ware anzupassen. Dies verlangt jedoch einen Mikrocom- 
puter-Entwickler, der bereit ist, mehr als einen Prozes- 
sor zu beherrschen. 
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Diese Netzteile wurden schwerpunktmäßig für den Bedarf in der Mikro- 
prozessortechnik und TTL-Technik entwickelt 

Alle Ausgänge sind kurzschlußfest und thermisch gesichert. Durch die 
Gewindebolzen auf der Ober- und Unterseite des Netzteils ist eine einfache 
Montagemöglichkeit gegeben. Auf der Epoxy-Druckplatte.-die im Europa- 
Steckkartenformat gehalten ist, sind die Lochungen für die gängigsten 
Stecksysteme nach DIN 41612 vorhanden. Von den serienmäßig ver- 
wendeten Steckstiften aus kann je nach verwendetem Bus-System 
die Steckleiste über Drahtbrücken frei codiert werden. Der Netz- 
anschluß erfolgt an der getrennten Anschlußplatine, die am Kühlkörper 
montiert ist 
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‚Dipl:-Inf. Johann Geyer 


32-Bit-Mikrocomputer besitzt 


neuartige Architektur 


‚Nach mehr als fünfjähriger Entwicklungszeit stellte 
Intel den 32-Bit-Mikrocomputer iAPX 432 vor, 
der verglichen mit bisher bekannten Strukturen 
eine völlig andere Architektur aufweist. Der Grund 
dafür liegt in dem Ziel, das schon zu Beginn der 
Entwicklungsarbeiten vorgegeben wurde, nämlich 
unter Ausnutzung der VLSI-Technologie eine Rech- 
nerarchitektur zu schaffen, die den Softwareer- 


1 Zielsetzung 


Vor fast zehn Jahren stellte Intel mit dem 4004 den 
ersten Mikroprozessor vor. Seitdem werden Mikro- 
prozessoren bei immer komplexeren Anwendungen 
eingesetzt. Dieses Anwachsen der Komplexität führte 
gleichzeitig, vor allem auf der Softwareseite, zu einem 
gravierenden Anstieg der Entwicklungskosten sowie 
zu einem Engpaß an geeigneten Systementwicklern 
und Programmierern. 

Bei allen Rechnersystemen, ob Großrechner, Mini- 
computer oder Mikroprozessoren, sind heute Ent- 
wicklungskosten für Software höher als die für Hard- 
ware. In vielen Fällen ist es sogar bereits so, daß die 
auf das Einzelsystem umgelegten gesamten Software- 
kosten höher sind als die Herstellungskosten der 
Hardware. Diese Tatsache ist vor allem dadurch zu 
erklären, daß in der Regel 70 % der Softwarekosten 
erst nach dem eigentlichen Entwicklungsabschluß 
entstehen. 

Diese oft auch als ‚‚Softwarekrise‘‘ bezeichnete Si- 
tuation war bereits Mitte der siebziger Jahre erkenn- 
bar; insbesondere durch Einführung der ‚„strukturier- 
ten Programmierung‘‘ wurde versucht, hier Verbesse- 
rungen zu erreichen. Eine 1975 bei Intel in den USA 
etablierte Gruppe von Entwicklern hatte das Ziel, die- 
ses Problem von einer anderen Seite her anzugehen. 
Beim Start des Projekts war gerade der Mikroprozessor 
8080 auf dem Markt, der 5500 Bauelemente in einem 
Chip enthält. Seinerzeit besagte das ‚Gesetz‘‘ von 
Gordon Moore, einem Gründer von Intel, daß sich die 
Anzahl der Bauelemente pro Chip alle ein bis zwei 
Jahre verdoppeln würde. Die Entwicklungsgruppe sah 
sich daher mit der Frage konfrontiert, was 1980 mit 
100 000 Einzelbauelementen auf einem Chip gesche- 
hen sollte. 


kenntnissen der siebziger Jahre entspricht, und die 
Grenzen zu überwinden, die bisher in bezug auf 
Leistung, Zuverlässigkeit sowie Funktionalität 
bestanden haben. Die Gesamtlösung umfaßt eine 
neuartige Architektur, realisiert in VLSI, Betriebssy- 
stemfunktionen in Silizium und eine Programmier- 
umgebung für ADA. 


Die Integration von 16 Mikroprozessoren des Typs 
8080 zu einem Bauelement wäre zwar alleine vom Lei- 
stungsgesichtspunkt aus interessant gewesen, jedoch 
hätte eine solche Feldrechnerarchitektur in keiner 
Weise Softwareprobleme gelöst, sondern im Gegenteil 
sogar neue geschaffen. 
Die Untersuchung komplexer Anwendungen im 
oberen Leistungsbereich von Mikroprozessoren und 
des Einsatzes von Minicomputern und Großrechnern 
ergab mehrere Gemeinsamkeiten. Daraus leiteten sich 
die Entwurfsziele für eine neue Architektur ab: 
® Diese Anwendungen sind sehr softwareintensiv; 
dabei laufen Programme für unterschiedliche Auf- 
gaben parallel zueinander ab und arbeiten teil- 
weise sogar mit gemeinsamen Daten. Als Beispiel 
dafür sei hier das Zusammenwirken von Waren- 
eingang, Buchhaltung, Lagerbestandsführung und 
Fertigungsvorbereitung in einem Industriebetrieb 
genannt. Für diese softwareintensiven Anwen- 
dungen müßte eine neue Rechnerarchitektur die 
Produktivität der Programmierer in allen Phasen 
unterstützen, um die Kosten der Erstellung, der 
Wartung und der Weiterentwicklung von Pro- 
grammen zu senken. 

© Diese Anwendungen erfordern eine hohe Verarbei- 
tungsleistung. In dieser Leistung muß auch die Un- 
terstützung von Datentypen und Laufzeitsystemen 
höherer Programmiersprachen sowie moderner 
und sicherer Betriebssysteme eingeschlossen sein. 
Im Maximalausbau müßte das zu entwickelnde Sy- 
stem über der Leistung der schnellsten Minicom- 
puter liegen und die von mittleren Großrechnern 
erreichen. 

© Gleiche Anwendungen erfordern oft stark unter- 
schiedliche Leistungen, z.B. Datenbankabfragen 
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von 5 oder 30 Terminals oder Vermittlungsrechner 
für 1000 oder 10 000 Telefonanschlüsse. Die Erwei- 
terbarkeit der Leistung — sogar im Feld — um einen 
sehr großen Faktor ohne jegliche Softwareände- 
rung, war von Anfang an Ziel beim Entwurf des 
iAPX 432. 
® Diese Anwendungen stellen hohe Anforderungen 
an die Zuverlässigkeit von Hard- und Software. Für 
Vermittlungsrechner der Deutschen Bundespost 
wird beispielsweise gefordert, daß sie innerhalb 
von 30 Jahren nur 2 Stunden ausfallen dürfen: 
Entwurfsziel der 432-Architektur war es daher, den 
Aufbau von ausfallsicheren Systemen zu ermögli- 
chen und die Auswirkungen von Softwarefehlern 
so klein und so lokal wie möglich zu halten. 
Während der Projektentwicklung erkannte man be- 
reits sehr früh, daß es zum Erreichen der oben gezeig- 
ten Ziele einer neuen Rechnerarchitektur bedurfte 
und daß diese keinerlei Kompatibilitätsanforderun- 
gen unterworfen sein durfte. Im folgenden wird das 
Ergebnis des Entwicklungsprojekts, die Architektur 
desiAPX 432 und zwar sowohl die Hardware als auch 
die Software beschrieben. 


2 Systemarchitektur 


Um die Leistung eines 432-Systems innerhalb einer 
großen Bandbreite erweitern zu können, wurde des- 
sen Architekur als Mehrprozessorsystem konzipiert. 
Minicomputer- und Großrechnerhersteller erreichen 
eine gewisse Variabilität in der Leistung oft durch ver- 
schiedene Implementierungen der gleichen Architek- 
tur, z. B. einmal mit Bit-Slices, ein anderes Mal mit 
ECL-Bausteinen oder durch mehr oder weniger starke 
Mikroprogrammierung. Diese Methoden fordern 
jedoch wesentlich höhere Entwicklungskosten und 
bieten zudem nicht die Möglichkeit der Leistungser- 
weiterung im Feld. Aus dem Gesichtspunkt der Zu- 
verlässigkeit ist hingegen ein Mehrprozessorkonzept 
überlegen, da hier beim Ausfall einer CPU nur die 
Verarbeitungsleistung zwar etwas sinkt, nicht aber 
das Gesamtsystem stillsteht. 

Die 432-Architektur implementiert vollständig das 
Konzept der ‚transparenten Mehrfachverarbeitung‘ 


Anforderung 


Daten 

Bild 1. Das Paketbus-Protokoll zerlegt einen 
Lesezugriff in zwei Pakete: Zum Zeitpunkt tı 
werden in der Anforderung die physikalische 
Anfangsadresse und die Anzahl der zu lesenden 
Bytes, zum Zeitpunkt tb werden die gelesenen 
Daten übertragen. Im Zeitraum zwischen t, und 
t, ist der Bus frei 
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(Multiprocessing), d. h. daß die Anzahl der Prozesso- 
ren in einem 432-System ohne jegliche Änderung der 
Software erhöht oder vermindert werden kann. Es 
können sogar während des Betriebs Prozessoren an- 
gehalten oder hinzugefügt werden, ohne auch nur 
einen Befehl im Betriebssystem oder Anwenderpro- 
gramm zu verändern. 

Diese Architektur bietet aber nicht nur die Möglich- 
keit, mehrere gleichartige Prozessoren miteinander zu 
verbinden, sondern auch unterschiedliche Prozesoren 
zusammenarbeiten zu lassen. 

Als erste Realisierungen wurden jetzt deriAPX 432 
General Data Processor (GDP) für die Verarbeitung 
von Programmen und der iAPX 432 Interface Proces- 
sor (IP) für die Ein-/Ausgabe vorgestellt. 

Ein grundsätzliches Problem bei Mehrprozessorsy- 
stemen stellt die Definition der Verbindung zwischen 
den einzelnen Prozessoren und dem Arbeitsspeicher 
dar. Statt diese Verbindung, also den Bus, festzulegen, 


‚spezifiziert die 432-Architektur nur, wie die einzelnen 


Prozessoren an den Bus angeschlossen werden, näm- 
lich über das Paketbus-Protokoll. 


2.1 Paketbus-Protokoll 


Die Kommunikation zwischen den Prozessoren und 
dem Speicher basiert auf der Grundlage von Paketen. 
Im Falle eines Lesezugriffes schickt ein Prozessor eine 
Anforderung an den Arbeitsspeicher, der nach einiger 
Zeit die gelesene Information, ebenfalls als Paket, zu- 
rückschickt (Bild 1). Bei einem Schreibzugriff über- 
trägt der Prozessor die Anforderungen zusammen mit 
den Daten in einem Paket zum Speicher. Eine Anfor- 
derung spezifiziert neben der physikalischen Spei- 
cheradresse auch, ob der Zugriff lesend, schreibend 
oder modifizierend (Read-Modify-Write) erfolgt, 
sowie die Anzahl der Bytes, auf die sich der Zugriff 
erstreckt, die variabel zwischen eins und sechzehn 
liegen kann. 

Das Paketbus-Protokoll hat den wesentlichen Vor- 
teil, daß es die Busbelegung vermindert, weil dieser 
nach der Übertragung eines Pakets sofort wieder frei 
ist, zwischen den zwei Paketen eines Lesezugriffs also 
andere Pakete über den Bus gehen können, und weil 


„Interface Processor" 


„General Data Processor" 


Bild 2. Mit Kreuzschienenarchitekturen lassen sich 432-Systeme mit der 
Leistungsfähigkeit mittlerer Großrechner aufbauen 


selbst bei längeren Datenelementen die Adresse nur 
einmal angegeben werden muß. Das Paketbus-Proto- 
koll erlaubt weiterhin, bis zu 16 Byte in einem Read- 
Modify-Write-Zyklus zu verändern sowie die direkte 
Übertragung von Nachrichten zwischen den einzel- 
"nen Prozessoren, um beispielsweise einen von ihnen 
anzuhalten. 


"2.2 Busstruktur 


Aufbauend auf diesem Paketbus-Protokoll lassen 
sich unterschiedliche Architekturen für die Verbin- 
dung zwischen den Prozessoren und dem Arbeits- 
speicher implementieren. Am einfachsten ist es wohl, 
den am Prozessor anliegenden Paketbus durch dis- 
"krete Logik zu entmultiplexen und die nun getrennten 
‚Adreß- und Datenleitungen in konventioneller Weise 
an den Speichermodul anzulegen. Bis zu vier Prozes- 
soren können ohne größere gegenseitige Beeinträch- 
tigung an diesen Bus angeschlossen werden. 

Ein völlig anderer, 32 Bit breiter Bus unterstützt im 
Platinensystem 432/200 bis zu sechs Prozessoren. 
432-Systeme maximaler Leistung können durch 
Kreuzschienenarchitekturen aufgebaut werden, in 
denen parallele Busse mehreren Prozessoren den 
gleichzeitigen Zugriff auf die einzelnen Speichermo- 
duln erlauben (Bild 2). 


2.3 Ein-/Ausgabe 


Ein wichtiges Merkmal der 432-Architektur ist es, 
die Verarbeitung der Programme von der Ein-/Aus- 
gabe zu trennen. Diese erfolgt in eigenständigen 
E/A-Untersystemem, die die Aufgabe der Gerätean- 
steuerung, der Interruptbehandlung und des Daten- 
transfers übernehmen. Diese E/A-Untersysteme be- 
stehen in der Regel aus einem Standardmikroprozes- 
sor wie dem 8086, der über einen eigenen Arbeitsspei- 
cher verfügt und die Peripheriebausteine bedient 
(Bild 3). 

Die Verbindung zwischen dem System und dem 
Mikroprozessor erfolgt über den 432 Interface Proces- 
sor (IP). Der IP ermöglicht es dem externen Mikropro- 
zessor auf den 432-Arbeitsspeicher zuzugreifen, in- 
dem er die physikalischen Adressen des Mikroprozes- 
sorsystems auf den 432-Adreßraum abbildet. Dazu 
kann der Mikroprozessor im IP sogenannte Fenster de- 
finieren, die bestimmte Adreßbereiche des Untersy- 
stems einzelnen Objekten im 432-Arbeitsspeicher 
zuordnen. Eines dieser Fenster ist für Blocktransfer 
optimiert, damit die Daten von oder zu schnellen Pe- 
ripheriegeräten direkt von einem DMA-Controller 
oder E/A-Prozessor 8089 durch das Fenster übrtragen 
werden können. Bei allen Zugriffen auf den 432-Spei- 
cher arbeitet der IP mit derselben objektorientierten 
Adressierungstechnik wie der GDP und überprüft 
auch die Zugriffsrechte in gleicher Weise. 

Alle Interaktionen zwischen Programmen eines 
432-Systems basiert aufdem Austausch von Nachrich- 
ten im Arbeitsspeicher; es gibt hier keine Interrupts. 
Um auch den Mikroprozessor des E/A-Untersystems 
in dieses Konzept einzubinden, kann dieser den IP 


Nachrichtengesteuert 






Interruptgesteuert 





DFÜ 


ETHERNET 

Bild 3. Standardmikroprozessoren übernehmen die Ein-/Ausgabe 
in einem 432-System. Die Verbindung zwischen der nachrichtenge- 
steuerten 432-Architektur und dem interruptgetriebenen E/A-Un- 
tersystem übernimmt der „432 Interface Processor“ 


durch Kommandos beauftragen, für ihn Nachrichten 
zu empfangen.oder zu senden. Die Ausführung eines 
solchen Kommandos meldet der IP durch einen Inter- 
rupt an den Mikroprozessor zurück. Eine empfangene 
Nachricht kann der Mikroprozessor anschließend 
über ein Fenster des IP adressieren. 

Der IP bietet dem externen Mikroprozessor eine 
Reihe von Kommandos an, die den Instruktionen und 
Hardwarefunktionen des sogenannten ‚„Betriebssy- 
stems in Silizium‘‘ des GDP entsprechen, und ‚erwei- 
tert‘‘ somit den Befehlssatz des Mikroprozessors um 
diese Eigenschaften. 

Die Anzahl der Interfaceprozessoren in einem 432- 
System ist ebenso variierbar wie die der GDPs, und 
damit sind sowohl Verarbeitungs- als auch Ein-/Aus- 
gabeleistung optimal an die einzelne Anwendung an- 
paßbar. Das Konzept der eigenständigen E/A-Unter- 
systeme bietet weiter die Möglichkeit, bereits heute 
bestehende Software unverändert weiterzuverwen- 
den, weil sie ja auf einem geeigneten Untersystem lau- 
fen kann. 


2.4 VLSI-Implementierung 


Die Prozessoren der 432-Familie werden in 
HMOS-Technologie gefertigt. Der 432 GDP enthält in- 
gesamt 160 000 Transistorfunktionen, die auf zwei 
Bausteine verteilt sind. Der 43201 mit seinen etwa 
100 000 Transistorfunktionen enthält ein 4-K x 16- 
Bit-Mikrocode-ROM und setzt die einzelnen Maschi- 
nenbefehle in Mikrobefehle um. Der 43202 führt 
diese aus und übernimmt die gesamte Adressierung 
(Bild 4). 

Der 432 Interface Processor entspricht etwa 60 000 
Transistorfunktionen und enthält ein 2-K x 16-Bit-Mi- 
krocode-ROM, bei dem mit einer neuen Technologie, 
die auch beim Numerik-Prozessor 8087 angewandt 
wird, in einer Zelle zwei Bits gespeichert werden. Be- 
dingt durch seine Funktion hat er einerseits die An- 
schlüsse zum 432-Paketbus, andererseits aber auch 
die Signale für die Mikroprozessorseite (Bild 5). 
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Bild 4. Der „iAPX 432 General Data Processor“ enthält etwa 
160 000 Transistorfunktionen auf zwei Bausteinen 


Bei beiden Prozessoren fällt die sehr regelmäßige 
Entwurfsstruktur und die starke Mikroprogrammie- 
rung auf. Nur dadurch ist es möglich, Bausteine sol- 
cher Komplexität zu entwerfen und zu testen. 

Für die 432-Bausteine mußte auch ein neues Ge- 
häuse entwickelt werden, das 64polige Quad-Inline- 
Package (QUIP). Es besteht aus einer Fassung, in dem 
ein Keramikträger, der den eigentlichen Chip enthält, 
durch eine Metallklammer festgehalten wird (Bild 6). 
Dieses Gehäuse bietet neben seiner Kompaktheit unter 
anderem den Vorteil, daß die Wärmeabgabe durch die 
Metallklammer sehr gut ist, wodurch der darunter be- 
findliche Chip relativ kühl bleibt 1). 


4 Metallklammer 


Abgreifpunkte 
für Signale 


Bild 6. Das speziell für die 432-Architektur entwickelte 64po- 
lige Quad-Inline-Package (QUIL) ist sehr kompakt und gibt die 
Wärme sehr gut ab; sämtliche Anschlüsse sind gut von außen 
abgreifbar 
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Adreßlogik, 
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Bild 5. Der „iAPX 432 Interface Processor“ enthält mehr 
als 60 000 Transistorfunktionen und verbindet zwei un- 
terschiedliche Busse 





2.5 Funktionsüberwachung durch Redundanztest 


Um den Aufbau besonders sicherer Systeme zu er- 
möglichen, bieten alle Bauelemente dieses Systems 
die Möglichkeit des sogenannten Functional Redun- 
dancy Checking (FRC). Dabei werden bei zwei glei- 
chen Bauteilen alle Anschlüsse direkt miteinander 
verbunden. Ein Baustein wird durch Anlegen von 5 V 
an einen speziellen Anschluß ‚Master‘, der andere 
durch Verbinden des entsprechenden Anschlusses 
mit Masse als „Checker“ definiert. Beide Bausteine 
laufen völligtaktsynchron und erhalten die gleiche In- 
formation auf ihren Eingangsleitungen. Der Checker 
überprüft bei jedem Takt was der Master an seinen 
Ausgängen erzeugt und vergleicht es mit dem, was er 
selbst intern generiert hat. Sobald die beiden Bau- 
steine bei irgendeinem Takt nicht übereinstimmen, 
erzeugt der Checker ein Signal, das den Master augen- 
blicklich blockiert. Gleichzeitig kann es in der Au- 
Benwelt als Fehlersignal verwendet werden (Bild 7). 


Durch das sofortige Anhalten der beiden Bausteine 
wird verhindert, daß falsche Information auf den Bus 
und damit in den Speicher gelangt. Mit dieser ohne 
jeden zusätzlichen Hardwareaufwand möglichen Me- 
thode können Systeme mit verschiedenem Zuverläs- 
sigkeitsgrad aufgebaut werden. 


> 


3 Softwarestruktur . 


Bereits in der Anfangsphase dieses Projekts standen 
alle daran Beteiligten vor dem Problem, die vielen Ar- 
chitekturmerkmale durch ein einheitliches Konzept 


zu verbinden, denn nur ein einheitliches Konzept, 
würde das Überprüfen, Erweitern und leichte Verste- - 


hen der komplexen Eigenschaften der 432-Architek- 
tur ermöglichen. Nach langen Untersuchungen ent- 
schied man sich, die erst Anfang der siebziger Jahre 
entwickelte Idee des ‚‚objektorientierten Entwurfs‘ als 
konzeptionelle Grundlage für den iAPX 432 heranzu- 
ziehen. Bei diesem „objektorientierten Entwurf‘ wird 
versucht, durch Modularität die für das Verständnis 
überflüssige Information zu verbergen und Daten zu 
abstrahieren |2, 3). 


Master-Modus 


Eingänge 


Checker-Modus 


Fehlersignal, falls 
Master und Checker 
nıcht übereinstimmen 


Bild 7. Im „Functional-Redundancy-Modus“ 
werden zwei Bausteine völlig taktsynchron mit- 
einander verglichen. Fehlende Übereinstimmung 
führt zum sofortigen Anhalten beider Bausteine 
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Bild 8. Die Adressierungsstruktur des iAPX 432 
gewährleistet volle Zugriffskontrolle, setzt die 
logische Adresse des Befehls in eine physika- 
lische um und unterstützt die virtuelle Spei- 
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Deswegen definieren auch Objekte alle wesentli- 
chen Eigenschaften des iAPX 432; er hat eine objekt- 
orientierte Architektur: 
® Adressierung und Zugriffsschutz: 

Objekte verwalten den logischen und physikali- 

schen Adreßraum und bilden die Grundlage für die 

Schutzmechanismen des iAPX 432. 

@ Allgemeine Verarbeitung: 

Datenobjekte unterstützen die allgemeine Verarbei- 

tung durch eine große Anzahl von primitiven Daten- 

typen. 
® Laufzeituntersützung von Sprachen: 

Domain- und Contextobjekte unterstützen die Lauf- 

zeitumgebung von ADA, aber auch prozedurale 

Sprachen wie COBOL und FORTRAN. 

@ Betriebssystem in Silizium: 

Prozessor-, Port- und Prozeßobjekte steuern die Zu- 

teilung der aktiven Betriebsmittel; Storage-Resour- 

ce-Objekte definieren die Zuteilung des logischen 
und physikalischen Adreßraumes. 


3.1 Adressierung und Zugriffsschutz 


Die gesamte Adressierung innerhalb der 432-Archi- 
tektur basiert auf dem Objektkonzept, wobei ein Ob- 
jekt aus einem oder mehreren Segmenten besteht. Ein 
Segment ist ein zusammenhängender Speicherbe- 
reich mit einer Länge zwischen 1 Byte und 64 KBpte. 
Jedes Objekt wird durch genau einen Objektdeskriptor 
beschrieben und kann auch nur über diesen adressiert 
werden. 

Ein Objektdeskriptor enthält die physikalische Ba- 
sisadresse eines Objekts, seinen Typ sowie seine Län- 
ge. Damit kann bei jedem Zugriff überprüft werden, ob 
ein Befehl auf Daten außerhalb des Objekts zugreift. 
Mehrere Bit unterstützen virtuelle Speicherverwal- 
tung, eines sagt z. B., ob das Objekt sich überhaupt im 
Arbeitsspeicher befindet. Um auf die einzelnen Ob- 
jektdeskriptoren in geordneter Weise zugreifen zu 
können, sind sie in einer zentralen Objekttabelle zu- 
sammengefaßt, die wiederum selbst ein Objekt ist; sie 
enthält somit auch ihren eigenen Objektdeskriptor. 





Zum Zugriff auf ein Objekt benötigt ein Programm 
einen speziellen Zugriffsdeskriptor, der auf den ent- 
sprechenden Objektdeskriptor zeigt; dazu enthält der 
Zugriffsdeskriptor einen Index in die Objekttabelle. 
Außerdem definiert der Zugriffsdeskriptor die Zu- 
griffsrechte des Programms auf ein Objekt. Damit kann 
erreicht werden, daß zwei Programme, deren jewei- 
lige Zugriffsdeskriptoren auf denselben Objektdes- 
kriptor, und damit auf dasselbe Objekt, zeigen, mit un- 
terschiedlichen Rechten darauf arbeiten können. 
Sämtliche Zugriffsdeskriptoren eines oder mehrerer 
Unterprogramme sind wiederum in einer Zugriffsliste 
zusammengefaßt (Bild 8); sie definiert die Zugriffs- 
umgebung dieses Programmteils (Context). Dieses 
Konzept bildet die Grundlage für die ‚„Need-to- 
know-“ oder „Capability-orientierte‘‘ Adressierung 4, 
5| der 432-Architektur: 
® Ein Programm kann nur auf ein Objekt zugreifen, 

wenn es einen Zugriffsdeskriptor darauf hat. 
® Ein Programm kann nur mit den im Zugriffsdes- 

kriptor angegebenen Rechten auf das Objekt zugrei- 
fen. Zugriffslisten sind ebenfalls von den Prozesso- 
ren erkannte Objekte. Es kann damit erreicht wer- 
den, daß nur spezielle Befehle auf ihnen operieren; 

Zugriffsdeskriptoren können also nicht wie nor- 

male Daten manipuliert und damit auch nicht ge- 

fälscht werden. 

Diese Adressierungsstruktur ermöglicht es dem 
iAPX 432 bei einem physikalischen Adreßraum von 
16 Megabyte einen logischen Adreßraum von 2* Byte, 
also tausend Gigabyte anzubieten. 

Damit die in Bild 8 gezeigte Adreßumsetzung über 
die im Arbeitsspeicher liegenden Tabellen nicht zu 
hohen Geschwindigkeitseinbußen führt, werden die 
Objektdeskriptoren der zuletzt benutzten Objekte in 
Cacheregistern auf dem Prozessor gehalten. Beim Zu- 
griff auf ein nicht im Cache beschriebenes Objekt wird 
der zugehörige Deskriptor automatisch auf den Pro- 
zessor geladen. Im allgemeinen garantiert die Lokali- 
tät von Programmen eine gute Trefferrate für den 
Cache. 
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40 0 

move kA, B, fmt , type 

43 0 

multify ‚A, B, fmt , type 

59 0 

multifly ‚A,B,C, fmt type 

83 0 
multiply , Ali) , B{j) , Cik) , fmt , type 


ds=b5 
Pb: 


a:=a 


a:=b*c; 


ali):=b(j)*c(k); 


a,b und c sınd ganze Zahlen (32 Bit) 


Bild 9. Viele Anweisungen aus höheren Programmierspra- 
chen lassen sich direkt in einen Maschinenbefehl umsetzen. 
Die Befehle und auch ihre einzelnen Felder sind bitvariabel 
lang 


3.2 Allgemeine Verarbeitung 


Die allgemeine Verarbeitung im iAPX 432 wird 
durch Datenobjekte unterstützt. Sie bestehen aus ge- 
nau einem Segment und enthalten primitive Datenty- 
pen. Die Referenz für ein einzelnes Datenlement wird 
innerhalb eines Befehls durch Angabe eines Segment- 
selektors und des Displacements gebildet (Bild 8). Der 
iAPX 432 GDP verarbeitet als primitive Datentypen: 
® Buchstaben und Boolesche Größen (8 Bit) 
® ganze Zahlen ohne Vorzeichen (8, 16 und 32 Bit) 
® ganze Zahlen mit Vorzeichen (16 und 32 Bit) 
® Gleitpunktzahlen (32, 64 und 80 Bit). 

Alle Formate sind kompatibel zum vorgeschlage- 
nen IEEE-Standard, damit also auch zum Numerik- 
prozessor 8087 |6.. Die Befehlsformate des iAPX 432 
GDP sind so ausgelegt, daß sie die Codegenerierung in 
Übersetzern vereinfachen und die Programmgröße 
reduzieren. Alle Instruktionen sind bitvariabel in der 
Länge, um eine optimale Codierung entsprechend ih- 
rer statistischen Häufigkeit zu erreichen. Der Befehls- 
zähler des Prozessors zeigt somit auch auf Bitpositio- 
nen innerhalb eines Befehlsobjekts. Die einzelnen Be- 
fehle können zwischen null und drei Referenzen ha- 
ben, wobei die Adressierungsarten so ausgelegt sind, 
daß sie alle Datenstrukturen höherer Programmier- 
sprachen direkt unterstützen, nämlich Skalare, stati- 
sche und dynamische Vektoren und Records. Auf die 
einzelnen Operanden wird entweder über Speicher- 
adressen zugegriffen oder sie stehen im Stack. Um 
speziell die Erstellung von Übersetzern zu vereinfa- 
chen, gibt eskeine von der Software aus ansprechbaren 
Register. 

Dieses Befehlsformat garantiert, daß viele Anwei- 
sungen aus höheren Programmiersprachen auch in 
einen einzigen Maschinenbefehl umgesetzt werden 
können. Bild 9 gibt hier einige Beispiele, die auch die 
Länge der Instruktionen in Bit enthalten. 


Genauso wie Datenobjekte die allgemeine Verarbei- 
tung von primitiven Datentypen unterstützen, erlau- 
ben komplexere Objekte die Ausführung höherlie- 
gender Funktionen. Die Hardware erkennt dabei im 
Objektdeskriptor eines solchen ‚„Systemobjekts‘‘ des- 
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Befehls-Segmente 


Domaın 


„Offentlich” | 


„Privat” 


Verweise auf andere 
Domainobjekte 


Bild 10. Domainobjekte sind Zugriffslisten, die die statische Zu- 
griffsumgebung eines Programmoduls definieren. Die in ihrem öf- 
fentlichen Teil gelegenen Zugriffsdeskriptoren sind auch von au- 
Berhalb erreichbar; die damit adressierten Befehlssegmente kön- 
nen also auch aus anderen Moduln aufgerufen werden 


sen genauen Typ und kann dann darauf Aktionen aus- 
führen, die in konventionellen Architekturen größe- 
ren Unterprogrammen entsprechen. 


3.3 Laufzeitunterstützung von Sprachen 


Domain- und Contextobjekte dienen in erster Linie 
der Laufzeitunterstützung von höheren Programmier- 
sprachen. Dabei definiert ein Domainobjekt die stati- 
sche Zugriffsumgebung eines Programmteiles; es ent- 
hält Verweise, d.h. Zugriffsdeskriptoren auf alle Un- 
terprogramme des Moduls und seine statisch angeleg- 
ten Daten (Bild 10). Ein modular aufgebautes Pro- 
gramm wird durch ein Netz miteinander verbundener 
Domainobjekte repräsentiert. 

Der „öffentliche‘‘ Teil eines Domainobjekts legt die 
Schnittstelle des Programmoduls nach außen fest. Die 
Zugriffsdeskriptoren im ‚privaten‘ Teil können nur 
innerhalb des Moduls angesprochen werden. Diese 
Unterteilung, die vollständig dem Package-Konzept 
von ADA entspricht, erlaubt die saubere Trennung der 
Schnittstellendefinition eines Moduls von dessen Im- 
plementierung, ist also ein Mittel, um unnötige Infor- 
mationen nach außen zu verbergen. 

Contextobjekte definieren die dynamische 
Zugriffsumgebung eines Prozeduraufrufs. Das Con- 
textobjekt wird beim Aufruf der Prozedur kreiert und 
bei der Rückkehr wieder zerstört, unterstützt damit 
also auf ideale Weise rekursive und Reentrant-Proze- 
duren. Der Context enthält auch ein Datenobjekt für 
die lokalen Daten und einen Operandenstock. 


Jeder Context ist mit einer Zugriffsliste verbunden. 
Befehle innerhalb des Contexts können nur Objekte + 
adressieren, die über diese Zugriffsleiste erreichbar 
sind. Die damit festgelegte Zugriffsumgebungiist voll- 
ständig mit dem Gültigkeitsbereich von Namen in ver- 
schiedenen Programmiersprachen ‘in Einklang zu 
bringen: In ADA wird die Erreichbarkeit von Varia- 
blen und Unterprogrammen durch die Package-Struk- 
tur bestimmt, in rein blockstrukturierten Sprachen 
wie ALGOL durch die umfassenden Blöcke und in- 
prozeduralen Sprachen wie FORTRAN ist im Prinzip 
aus jeder Anweisung der gesamte Programmbereich 


ansprechbar. Damit kann ein Übersetzer für jede Pro- 
grammiersprache die entsprechenden Zugriffslisten 
aufbauen. 


3.4 Betriebssystem in Silizium 


Die wohl markanteste Eigenschaft der 432-Archi- 
tektur/ist, daß Funktionen, die sonst im Betriebssy- 
stemkern zu finden sind, hier direkt in die Hardware 

‚ integriert,‚wurden. Grundlage dafür bilden die folgen- 

‚ den Systemobjekte, die den wichtigsten Betriebsmit- 

teln und Systemdiensten entsprechen: 
@ Prozessorobjekt: 

Für jeden physikalischen Prozessor gibt es eine Da- 

tenstruktur im Speicher, die ihn genau beschreibt 

und ihm Informationen über seine Systemumge- 

„ bung gibt. 

® Prozeßobjekt: 

* Jeder Prozeß (Task) im System ist durch solch ein 
Objekt beschrieben. Ein Prozeß ist eine Programm- 
einheit, die parall zu anderen Prozessen ausgeführt 
werden kann. Ein Prozeßobjekt enthält unter ande- 
rem Information über die Priorität und die Zeit- 
scheibe des Prozesses. 

@ Portobjekt: 

Portobjekte sind Datenstrukturen, die die Funktion 
einer Warteschlange erfüllen. Sie können somit bei 
der Interprozeßkommunikation als Nachrichten- 
puffer zwischen einzelnen Prozessen dienen, aber 
auch im Rahmen der Rechnerkernvergabe die lauf- 
fähigen Prozesse aufreihen. Die zweite Funktion 
wird dadurch erreicht, daß die Zuteilung eines Pro- 
zessors als das Senden einer Nachricht (des Prozeß- 
objekts) an einen physikalischen Prozeß (den Pro- 
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lauft auf Prozessor 2 


Domain des Contexts 


zessor) interpretiert wird. In Portobjekten können 
die einzelnen Elemente in FIFO-Ordnung, aber 
auch entsprechend ihrer Priorität und/oder Zeit- 
grenze eingereiht werden. 


@ Storage-Resource-Objekt (SRO): 

Ein SRO ist ein Objekt, das die dynamische Frei- 

speicherverwaltung im System unterstützt. Es be- 

schreibt einen oder mehrere Teile des Arbeitsspei- 
chers, aus dem Programme durch den Befehl 

„CREATE SEGMENT“ neue Objekte generieren 

können. Die gesamte Suche innerhalb des SROs 

nach einem zusammenhängenden Stück ausrei- 
chender Größe, alle nötigen Verkettungen und die 

Übergabe des Zugriffdeskriptors für das neue Ob- 

jekt werden von der Hardware vorgenommen. Zur 

Implementierung unterschiedlicher Zuteilungs- 

strategien können mehrere solcher Storage-Resour- 

ce-Objekte im System existieren. 

Ähnliche Datenstrukturen existieren sicher in fast 
allen Rechnern; der wesentliche Unterschied zum 
iAPX 432 besteht allerdings darin, daß die Hardware 
die einzelnen Objekte erkennt und Befehle sowie un- 
sichtbare Funktionen darauf definiert sind. Die Zutei- 
lung eines Prozessors an einen Prozeß (= Dispatching) 
sowie das Einsortieren eines Prozesses in die Warte- 
schlange (Dispatching Port) der lauffähigen Pro- 
gramme (= Scheduling) werden in der 432-Architek- 
turautomatisch von den einzelnen Prozessoren ausge- 
führt, ohne daß auch nur ein einziger Befehl dafür er- 
scheint. Dadurch ist auch das softwaretransparente 
Multiprozessing möglich; jeder freie Prozessor nimmt 
sich nämlich selbsttätig aus der Warteschlange der 
lauffähigen Prozesse den in der Reihenfolge ersten 






Prozesse, die auf 
Nachrichten warten 


mn nenn 


Prozeß - Prozel- 
objekt objekt 
ER: 






” 


Nachrichten , die auf 
Empfang warten 


Bild 11. Die einzelnen Objekte eines 
typischen 432-Systems sind unter- 
einander verknüpft, die Pfeile stellen 
Zugriffsdeskriptoren dar 
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PASCAL 
type 
Weekday = (Mon, Tue, 
Wed, Thu, Fri, Sat, Sun); 
Date = record 


ADA 


type Weekday is (Mon, Tue, 
Wed, Thu, Fri, Sat, Sun); 
type Date is 
record 


Day: 1..31; Day: integer range 1..31; 
Month: 1..12; Month: integer range 1..12; 
Year: 0..4000; Year: integer range 0..4000; 
DayOfWwk: Weekday; DayOfWk: Weekday; 
end; end record; 
DatePointer = * Date; type DatePointer is access Date; 
Var i 
D: Date; D: Date; 


D2: array (1..20) of Date; D2: array (1..20) of Date; 


Prozeß heraus und beginnt mit seiner Ausführung. Er 
braucht dazu überhaupt nicht zu wissen, wie viele an- 
dere Prozessoren im System existieren. Nach Ablauf 
der Zeitscheibe eines Prozesses oder beim Auftreten 
einer Wartebedingung sortiert der Prozessor das Pro- 
zeßobjekt in die entsprechende Warteschlange ein 
und ist wieder frei. 

Das Portmodell dient auch zur Übertragung von 
Nachrichten zwischen asynchron zueinander ablau- 
fenden Prozessen. Ein Port wirkt als Zwischenpuffer 
für Nachrichten, deren Empfänger noch nicht bereit 
ist, die Nachricht zu übernehmen; er ist eventuell 
noch gar nicht gestartet. Ähnlich wird auch ein Emp- 
fängerprozeß, der aus einem im Augenblick leeren 
Port empfangen möchte, von seinem ausführenden 
Prozessor angehalten und an den Port „angebunden‘‘; 
der Prozessor ist anschließend frei und kann wieder 
mit dem Dispatching beginnen. Sobald zu einem spä- 
teren Zeitpunkt ein Prozessor bei der Ausführung ei- 
nes Prozesses durch den Befehl „SEND MESSAGE“ 
eine Nachricht an diesen Port schickt, legt der Prozes- 
sor den Verweis auf die Nachricht direkt im Prozeßob- 
jekt des wartenden Prozesses ab und ordnet es auch 
automatisch in die Warteschlange der lauffähigen 
Prozesse ein. 

Im Bild 11 wird ein Überblick über die wichtigsten 
Objekte in einem 432-System und ihr Zusammenhang 
untereinander gegeben. Für viele Objekte gibt es Ana- 
logien zu konventionellen Rechnern; der gravierende 
Unterschied besteht darin, daß deriAPX 432 alle diese 
Objekte mit Hilfe von Hardware erkennt und die Ope- 
rationen darauf einzelne Befehle sind oder sogar au- 
tomatisch ablaufen, womit die Architektur des iAPX 
432 speziell für diese Funktionen um ein Vielfaches 
schneller ist als jeder andere Rechner. 
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PASCAL ADA 

package Processes is 
type process is private; 
type priority is integer range 1..50; 
function Create(p:priority) return process; 
procedure Destroy(p:process); 

end Processes; 


Nicht 
verfügbar 


Bild 13. Das Packagekonzept in ADA unterstützt die Modularisie- 
rung von großen Programmpaketen 


«Bild 12. 
Viele Sprachelemente von ADA gehen auf PASCAL zurück, speziell 
Vereinbarungen und Ausdrücke sind sehr ähnlich 


4 Programmierumgebung 


Zur Erstellung von Software für den iAPX 432 dient 
die Programmiersprache ADA. Diese Sprache ist nach 
einem fünfjährigen Auswahlprozeß aus einem Projekt 
des amerikanischen Verteidigungsministeriums her- 
vorgegangen und im August 1980 endgültig verab- 
schiedet worden [7]. Neben den guten leistungsfähi- 
gen Eigenschaften der Sprache selbst wird vor allem 
die Entscheidung des amerikanischen Verteidi- 
gungsministeriums, ab 1983 neue Software nur noch 
in ADA zu akzeptieren, dazu führen, daß sich ADA 
sehr schnell und in breiter Front durchsetzen wird. 


ADA wurde speziell für die Erstellung großer Soft- 
warepakete konzipiert und erinnert in vielen Teilen 


sehr stark an PASCAL (Bild 12), bringt jedoch einige 

wichtige neue Eigenschaften: 

® Multitasking und Prozeßkommunikation werden 
unterstützt. 

® Das Packagekonzept erlaubt die saubere Modulari- 
sierung von großen Programmpaketen. Durch die 

Trennung der Schnittstellendefinition eines Pak- 

kage von seiner eigentlichen Implementierung 

wird das Projektmanagement großer Softwarepa- 

kete erleichtert (Bild 13). 

Obwohl ADA und das Konzept des iAPX 432 voll- 
kommen getrennt voneinander entstanden sind, kann 
man ihre Strukturen genau aufeinander abbilden: 
® Ein ADA-Objekt entspricht einem 432-Objekt. 
® Ein ADA-Access entspricht beim iAPX 432 einer 

Objektreferenz. i 
@ Ein ADA-Package entspricht einer 432-Domain. » 
® Die Aktivierung eines Unterprogramms in ADA 

entspricht dem Context beim iAPX 432. i 

Aus unterschiedlichen Richtungen sind also zwei 
unabhängige Gruppen von Entwicklern zum gleichen 


Ergebnis gekommen. Auch dies unterstreicht .die 
Überlegenheit der Architektur des iAPX 432. 
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Dipl.-Math. Reiner Mauthe 


Mehrprozessor-Unterstützung in 
Echtzeit-Betriebssystemen 


Man unterscheidet im wesentlichen zwei Arten der 
Mehr-Prozessor-Technik: transparentes und nicht- 
transparentes Multiprocessing. Transparent bedeutet, 
daß sich die Prozessoren in einem System die gesam- 
ten Aufgaben teilen, kein Prozessor wird bevorzugt. 
Vorteil dieses Verfahrens ist die Möglichkeit, den 
Durchsatz des Systems zu steigern, indem man wei- 
tere Prozessoren hinzufügt. Der Ausfall eines Prozes- 
sors bedeutet nur eine Leistungsminderung, aber 
keine Funktionsstörung. Es gibt nur ein Betriebssy- 
stem für die Gesamtkonfiguration, das die Prozesso- 
ren als gemeinsame Mittel verwaltet. Der Verwaltungs- 
aufwand im Betriebssystem wird wesentlich erhöht, 
wenn solche Funktionen nicht direkt in der Hardware 


Leistungssteigerung durch mehrere Prozessoren 


Es gibt zwei Möglichkeiten, die Leistungsfähigkeit 
eines Systems zu erhöhen: 

1. Den existierenden Prozessor durch einen leistungs- 
fähigeren ersetzen; 
2. weitere Prozessoren hinzufügen. 

Die erste Alternative bedeutet normalerweise das 
Umsteigen auf einen größeren Rechner. Dies ist meistens 
sehr kostspielig, da sowohl Teile der Hardware geändert 
werden müssen, als auch die Software, um kompatibel 
zum neuen Rechner zu sein. 

Dieses Problem könnte vermieden werden, wenn von 
Beginn an ein größerer Rechner vorgesehen wird, um für 
zukünftige Erweiterungen gerüstet zu sein. Aber ein 
solches Konzept ist meistens zu kostspielig und unter 
der Randbedingung möglichst schnell ein Produkt zu 
entwickeln, nicht durchsetzbar. Die zweite Alternative, 
weitere Prozessoren hinzufügen, ist für den Benutzer 
nur dann sinnvoll, wenn in seiner Anwendung mehrere 
Tasks existieren. die gleichzeitig mit dem Prozessor 
arbeiten könnten. In einer RMX-Umgebung sind dies 
alle Tasks, die sich im laufenden Zustand oder sich in 
der „Ready“-Warteschlange befinden. Unter diesen 
Umständen ist es möglich, diese Tasks auf mehrere 
Prozessoren zu verteilen und gleichzeitig ablaufen zu 
lassen. 


implementiert sind. Ein Beispiel eines transparenten 
Multiprozessor-Systems mit Scheduling-Funktionen, 
die in der Hardware direkt implementiert sind, ist der 
iAPX 432 [1]. Nichttransparentes Multiprocessing 
bedeutet, daß jeder Prozessor im System eine spe- 
zielle Aufgabe übernimmt. Jeder Prozessor hat sein 
eigenes Betriebssystem. Im Fehlerfall ist er damit 
nicht in der Lage, die Rolle eines anderen Prozessors 
zu übernehmen. MMX800 [2] bietet die Möglichkeit der 
Kommunikation zwischen den Betriebssystemen 
RMX/80 [4], RMX/88 [5] und RMX/86 [3]. Es ist damit 
möglich, sowohl ein 16-Bit-Mehrprozessorsystem zu 
realisieren als auch ein gemischtes 8- und 16-Bit- 
System aufzubauen. 


Die meisten Echtzeit-Systeme enthalten Tasks, die 
gleichzeitig ablaufen könnten. Diese bearbeiten asyn- 
chrone Ereignisse der Außenwelt. Deshalb haben die 
Tasks nicht notwendigerweise eine strikte Reihenfolge, 
in der sie abgearbeitet werden müssen. In solchen Fällen 
eignet sich der Einsatz mehrerer Prozessoren in einem 
Echtzeit-System. 

Das Übertragen von Software von einem Ein- auf ein 
Mehrprozessorsystem bringt natürlich neue Probleme 
mit sich. Obwohl Echtzeit-Tasks i.a. im Verhältnis 
zueinander asynchron ablaufen, ist in vielen Fällen eine 
Kommunikation zwischen diesen Tasks durchzuführen. 
Deswegen muß auch die Möglichkeit einer Inter-Task- 
Kommunikation in einer Mehrprozessorumgebung vor- 
handen sein, was das ursprüngliche Softwarekonzept 
nicht sehr stark beeinflussen sollte. In einer Multibus- 
Umgebung wird ein Mehrprozessorsystem durch die 
Verwendung mehrerer Einplatinen-Computer realisiert. 
Der Zugriff auf den Multibus durch diese Boards wird 
durch eine Hardware-Entscheidungslogik geregelt. Da 
jeder dieser Computer sein eigenes Betriebssystem besit- 
zen kann, ist eine Kommunikation zwischen diesen 
Boards in der Regel nicht vorhanden. Die folgenden 
Abschnitte behandeln die Software MMX800 und den 
Zusammenhang zu den RMX-Betriebssystemen. Damit 
wird dem Benutzer die Möglichkeit gegeben, Inter-Task- 
Kommunikation zwischen Einplatinen-Computern zu 
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betreiben, um damit die Vorteile einer Mehrprozessor- 
umgebung auszunutzen. 


Software MMX800 


Die „Multibus Message Exchange Software“ MMX800 
[2] ist eine logische Erweiterung der Inter-Task-Kommu- 
nikations-Mechanismen des Betriebssystems RMX/86. 
Die sendende Task schickt eine Nachricht an eine „Mail- 
box“ an der die empfangende Task wartet. Die Imple- 
mentierung des Nachrichtenaustauschs ist natürlich 
unterschiedlich zu RMX/86, da es die Zusammenarbeit 
zweier Betriebssysteme erfordert. Die Systemaufrufe für 
MMX800 zeigen dies: 


ACTIVATE PORT 


stellt für die empfangende Task die Verbindung zwi- 
schen der Mailbox auf der Platine und dem global 
bekannten Systemportnamen her. An dieser Mailbox 
können dann die Nachrichten empfangen werden, die 
von Tasks auf anderen Boards geschickt werden. 


FIND PORT 


liefert der sendenden Task eine Identifikation (Token) 
zurück, die es mit dem TRANSFER-Aufruf erlaubt, eine 
Nachricht an eine Mailbox zu schicken. Diese Mailbox 


stellt wiederum die Verbindung zum globalen System- 
port dar. 


TANSFER MESSAGE 


leitet einen MMX800-Nachrichtentransfer ein und 
schickt eine Nachricht an den angegebenen Systemport. 


LOSE PORT 


hebt die Verbindung, die durch „FIND PORT“ zustande 
gekommen ist, wieder auf. 


DEACTIVATE PORT 


ist das entsprechende Gegenteil zu „ACTIVATE PORT“. 


Um eine Nachricht an eine Task auf einem anderen 
Computer zu schicken, wird zuerst ein Aufruf „FIND 
PORT“ mit dem gewünschten Systemportnamen abge- 
setzt. Die Task setzt dann einen Aufruf „TRANSFER 
MESSAGE“ für jede zu sendende Nachricht ab. Ein 
Parameter dieses Aufrufs ist die vom Betriebssystem 
zurückgegebene Identifikation für den Systemport, an 
den diese Nachricht geschickt wird. Um eine Nachricht 
zu empfangen, setzt die Task zuerst einen Aufruf „ACTI- 
VATE PORT“ ab. Die Task wartet danach an der Mail- 
box, deren Adresse durch den Aufruf vom Betriebssy- 
stem zurückgegeben wird. Weitere Nachrichten können 
an der gleichen Mailbox durch zusätzliche Aufrufe emp- 
fangen werden. 











IMMX 800 - 
Verbindung 
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Bild 1. Möglichkeiten zur Steigerung der Systemleistung: 
a) Ein-Prozessor-System, b) System mit zwei Computer- 
platinen 








System 2 


System 1 
nn 











„Find Port” „Activate 
(CQFIND) Port“ 
(CQACTV) 





« 


„Receive Msg” #,- 





Exception- 
Handler 















=> 
ja 


„Transfer Msg” 
(CAXFER 
(Connection)) 


nein _ 
andere 
Message? 


nein 













(local system 
call(s)) 
andere 
Message? 4 


k ; nein 
Exception- € Deaktiviere 
(CADACT) n 











Bild 2. Schematischer, 
Ablauf des Nachrich- 
tenaustauschs beim 
iMMX800 





„Lose Port” 


(CQLOSE) 








86 


„LOSE PORT“ und „DEACTIVATE PORT“ sind nicht 
für den Meldungsaustausch notwendig. Sie geben nur 
die Betriebsmittel wieder an das Betriebssystem zurück. 
Ein schematischer Ablauf ist in Bild 2 dargestellt. 


Beispiel eines Mehrprozessorsystems 


„Bild 1a stellt’eine Konfiguration für eine Echtzeit- 
Anwendung.mit vier Tasks dar, die auf einem Einplati- 
nen-Computer ablaufen. Es wird angenommen, daß 
diese Tasks zusammen den Prozessor zu 100 Prozent 
auslasten, d. h., keine CPU-Zeit vergeudet wird. Wenn 
man-annimmt, daß z. B. Task 1 und 3 sowie Task 2 und 4 
häufig gleichzeitig im „Ready-“ bzw. „Runnig-“ Zustand 
sind, heißt das, daß diese Kombinationen logisch gleich- 
zeitig ablaufen könnten. Um hier nun einen höheren 
Durchsatz zu erreichen, wählt man eine Konfiguration, 
wie sie Bild 1b zeigt. Task 1 und 3 sowie Task 2 und 4 
sind nun auf verschiedenen Rechnern, was ihnen auch 
physikalisch die gleichzeitige Ausführung erlaubt. Da 
Task 2 und 3 bzw. Task 1 und 4 auch Inter-Task- 
Kommunikation benötigen, wird MMX800 verwendet. 
Der tatsächliche Gewinn an Durchsatz ist nicht der 
Faktor 2, weil hier zwei Prozessoren beteiligt sind. Er 
hängt von zusätzlichen Randbedingungen ab, wie z.B. 
die Prozessorzeit, die jede einzelne Task für sich in 
Anspruch nimmt. 


Modularität eines Systems 


Eine Tendenz eines Mehrprozessorsystems ist die 
Spezialisierung der einzelnen Subsysteme für eine 
bestimmte Aufgabe. Es kann eine Peripherieeinheit 
eines Einplatinen-Computers als Datenbasis für das 
gesamte Multibussystem benutzt werden. Ebenfalls 
kann eine Numerikeinheit (hier SBC 337 mit 8087) Floa- 
ting-Point-Funktionen für das Gesamtsystem zur Verfü- 
gung stellen. Dieses Konzept eines Mehrprozessorsy- 
stems kann durch den Einsatz des Ethernet-Kommuni- 
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Bild 3. Beispiel für ein verteiltes 
System mit gemeinsamer Datenbasis 








kationsboards SBC 550 [6] noch erweitert werden (Bild 
3). Alle MMX800-Verbindungen benutzen auf dem Mul- 
tibus das gleiche Hardwareprotokoll. Dieses Protokoll 
MIP (Multibus Interprozessor Protocol) ist in [2] be- 
schrieben. 


Zusammenfassung 


Die RMX-Betriebssysteme zusammen mit der Erweite- 
rung MMX800 erlauben einen modularen Aufbau einer 
Echtzeit-Anwendung. Ein Multibus-System kann ohne 
prinzipielles Redesign des Gesamtsystems schrittweise 
aufgerüstet werden. Das System kann man in funktio- 
nelle Untersysteme aufteilen, die ihre speziellen Dienste 
dem Gesamtsystem zur Verfügung stellen. Auf diese 
Weise sind auch zukünftige Entwicklungen einfach in 
das gesamte System zu integrieren. 
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Dipl.-Ing. Jens-Peter Gast 


IC steuert zweiseitigen Speicher 


Leistungsfähige Mikrocomputer ermöglichen die Pro- 
jektierung von Prozeßsteuerungen und -regelungen 
mit Eigenschaften, die den bisherigen Lösungen in 
konventioneller Hybridtechnik überlegen sind. Dies 
gilt vor allem auch für Funktionserweiterungen zur 
Erleichterung von Inbetriebnahme, Änderungen, War- 
tung sowie für Maßnahmen zur Erhöhung der Verfüg- 
barkeit. Zur Abdeckung der verschiedenen Anforde- 
rungen eines Aufgabenspektrums ist ein hoher Grad 
von Modularität bei Hard- und Software notwendig. 
Dazu gehört auch die Anwendungsmöjglichkeit eines 
Hardwaremenüs in verschiedenen Multiprozessor- 


1 Aufgaben der Steuerung eines zweiseitigen 
Speichers 


Der Aufbau eines zweiseitigen Speichers, eines von 
zwei Mikrocomputern erreichbaren Schreib- und Lese- 
speichers, wird in Bild 1 dargestellt. Die beteiligten 
Prozessoren müssen nicht TRIRPTIEINEN und frequenz- 
gleich arbeiten. 
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Bild 1. Prinzipbild des zweiseitigen Speichers 
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Konfigurationen [1]. 

Eine Art der Rechnerkopplung, die Speicherkopplung, 
ist im Rahmen einer vom Bundesminister für For- 
schung und Technologie (BMFT) geförderten Arbeit - 
Entwicklung einer Datenübertragung auf Bahnfahr- 
zeugen über Lichtleiter — zunächst für dieses und 
ähnliche Aufgabenspektren [2, 3] entwickelt worden. 
Das Ergebnis, ein einziger Integrierter Schaltkreis zur 
Steuerung der Speicher, aller Daten- und Adreßbus- 
puffer sowie der beteiligten Mikroprozessoren, ist uni- 
versell, auch für verschiedene Prozessortypen, 
anwendbar. Die Steuerung benötigt keine Software. 


Die Aufgaben der Zugriffssteuerung ergeben sich aus 
der Anordnung: 

— Erkennung der Zugriffswünsche; 

— Vergabe der Priorität an einen Prozessor; 

— Sperren des Konkurrenten, jedoch nur dann, wenn 
dieser während eines laufenden Zugriffs des priori- 
sierten Rechners ebenfalls zugreifen will; 

— Steuerung der Datenbuspuffer-Schnittstellen; 

— Steuerung der Adreßbuspuffer-Schnittstellen; 

— Steuerung der Speicherblöcke. 

Daraus ergibt sich die innere Struktur des Steuerbau- 
steins, die in Bild 2 dargestellt ist. 


2 Funktionsbeschreibung > 


Bei zwei im allgemeinen nicht taktsynchron und fre- 
quenzgleich arbeitenden Mikrocomputern, die auf einen 
gemeinsamen Speicherbereich konfliktfrei zugreifen 
sollen, hat man bei rein hardwareseitiger Steuerung der 
Zugriffe nur eine Möglichkeit, bei gleichzeitigem Lesen 
und Schreiben von beiden Rechnern die Priorität, zu 
vergeben: Der zeitlich zuerst zugreifende Prozessor muß 
seinen Zugriff ungestört zu Ende durchführen können. 

Kriterium für die Zugriffswünsche sind die aus den 
Adreßleitungen decodierten SELECT-Signale der Berei- 
che des gemeinsamen Speichers. Sie sind auch ein Maß 
für die Dauer der Zugriffe. 

Der Funktionsblock „Priorität“ (Bild 2) ordnet jedem 
der beiden Prozessoren, der zeitlich zuerst zugreift, den 
internen Status „FAC“ (Erster) zu. Das bedeutet für 


diesen Prozessor einen ungestörten Ablauf des Zugriffes 

mit entsprechender Steuerung der zugehörigen Buspuf- 

fer und Speicherselect-Signale. Der Konkurrent bleibt 
ebenfalls ungestört, solange er nicht auf einen gemeinsa- 
men Speicherbereich zugreifen will. Wird jedoch aus 

‚dessen Adreßleitungen eine dafür gültige Adresse deco- 

diert, also ein Zugriffswunsch erkannt, erhält dieser 

Prozessor- sofort den Status „NOT READY“ mit der 

Folge, daß die’ Steuerleitung „READY“ auf logisch „O0“ 

geht. Er kann während eines laufenden Zugriffes des 

Prozessors mit dem Status „FAC“ nicht mehr ungestört 

zugreifen. Daher werden auch die Steuersignale für die 

zugehörigen Buspuffer und den angesprochenen Spei- 

‚cherhlock während „NOT READY“ unterdrückt. „NOT 

READY“ bewirkt bei dem betroffenen Prozessor, nach 

taktabhängiger Erkennung, einen Übergang in den 

„WAIT STATE“; nach außen bedeutet dies sozusagen 

ein „Einfrieren“ aller Zustände der Bus- und Steuerlei- 

tungen des unterbrochenen Prozessors. Dies bedeutet 
aber auch, daß dessen Zugriffswunsch, also die gültige 

Adresse im gemeinsamen Speicherbereich, weiter an- 

steht. 

Beendet der Prozessor, der den Status „FAC“ erhalten 
hatte, nun seinerseits den Zugriff, indem dessen Adreß- 
bus z.B. die Adresse des nächsten zu decodierenden 
Befehls im Programmspeicher annimmt, erhält nunmehr 
sofort der bisher wartende Prozessor den Status „FAC“. 
Damit wird er „READY“ und verläßt, nach wiederum 
taktabhängiger Auswertung dieses Steuersignales, den 
„WAIT STATE“ und führt den unterbrochenen Zugriff 
zu Ende, da nun auch die Unterdrückung der Steuerung 
der Puffer und des Speicherselect-Signales intern aufge- 
hoben ist. 

Der Sonderfall des absolut gleichzeitigen Zugriffes, 
mit einem vorhergehenden Bereich des nahezu gleich- 
zeitigen Zugriffes, wird intern auf zwei verschiedenen 
Wegen gelöst: 

—- Im Grenzbereich des nahezu gleichzeitigen Zugriffes 
kann durch externe Verbindung jeweils zweier von 
drei Anschlüssen der eine oder der andere Prozessor 
bevorzugt werden. Gleichzeitig kann durch entspre- 
chende Beschaltung der beiden Steuereingänge durch 
externe Logik der eine oder der andere Prozessor nach 
dem ersten Zugriff in einen dauernden „WAIT 
STATE“ versetzt werden. Dieser „WAIT STATE“ dau- 
ert dann solange, bis der Steuereingang wieder freige- 
geben wird, eine Option, die bei „Direktem Speicher- 
zugriff‘ (DMA) in den Koppelspeicher benötigt wird. 

— Bei zufällig absolut gleichzeitigem Zugriff reagiert die 
Logik der Zugriffssteuerung derart, daß derjenige Prio- 
rität für ungestörten Zugriff behält, der auch beim 
letzten, zeitlich davorliegenden Konflikt den Status 
„FAC“ zuletzt erhalten hatte. 

Das Anschlußbild des Integrierten Schaltkreises zeigt 
Bild 3. Die Schaltung ist in CMOS-Metal-Gate-Technik 
ausgeführt und in einem 28poligen Keramikgehäuse 
untergebracht. Alle Signale sind TTL-kompatibel, der 
Schaltkreis ist für den erweiterten Temperaturbereich 
spezifiziert. 


Die Signalgruppen haben folgende Bedeutung: 
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CSAK Speicherselect-Signale, Low-aktive, an 

..BK maximal vier Adreßblöcke 

„CK 

„DK 

G Grenzbereichsausgang „Beide READY 
Low“ 

A,B Prozessor 1 (A) oder 2 (B) „NOT REA- 


DY‘“ ab nächstem Zugriff für die Dauer 
des Low-aktiven Eingangssignales; zu- 
gleich zusätzliche „FAC“-Setzeingänge 
im Grenzbereich. 
Einen Prototyp des Integrierten Schaltkreises „DARC“ 
zeigt Bild 4. 


3 Anwendungen 


Es ist häufig wirtschaftlicher, hohen Datendurchsatz 
nicht mit einem schnellen und daher überproportional 
teuren, sondern mit mehreren 8- oder 16-Bit-Mikrocom- 
putern zu realisieren [1]. Dies gilt vor allem dann, wenn 
auch die zu steuernden und regelnden Prozesse in klar 
trennbare Teilbereiche aufgegliedert werden können, 
die so dann auch auf die einzelnen Bereichsrechner 
hard- und softwareseitig verteilt werden können. Hier 
bietet sich die Speicherkopplung als Bindeglied deshalb 
besonders an, weil sie im Gegensatz zu allen anderen 
bekannten Kopplungsmöglichkeiten keinerlei Software 
für diese Funktion benötigt. Die Kopplung der Teilpro- 
zesse erfolgt allein über vereinbarte Datenspeicher- 
adressen in beiden Richtungen. 
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Bild 4. Zugriffssteuerung „DARC“ als Integrierter Schaltkreis 
(Foto: AEG/J.-P. Gast) 


Bezogen auf die Zahl der Speicherzugriffe ist darüber 
hinaus auch die Zahl der Konflikte klein, so daß der 
Verlust an Operationszeit durch „WAIT STATES“, und 
dies ohnehin dann nur für die restlichen Zugriffszeiten 
der jeweiligen Konkurrenten, praktisch unbedeutend 
ist. 

Je nach Anordnung des Gesamtsystems, lineare oder 
ringförmige Anordnung gleichberechtigter Mikrocom- 
puter oder sternförmige Anordnung am Bussystem eines 
zentralen Rechners, ergeben sich verschiedene vom Auf- 
gabenspektrum abhängige Möglichkeiten. 

Die Aufteilung von Teilbereichen eines Prozesses auf 
speichergekoppelte Bereichsrechner ergibt noch einen 
weiteren Vorteil, der vor allem dort greift, wo Betriebs- 
mittel und, besonders wichtig, Menschen vor den Fol- 
gen von Fehlfunktionen unbedingt geschützt werden 
müssen (zZ. B. bei Bahnanwendungen). 

Einige wenige zusätzliche Schnittstellen und Zusatz- 
software zur gegenseitigen Überwachung aller Teilsy- 
steme über die Speicherschnittstellen gestatten bei Teil- 
ausfällen deren Erkennung und Durchführung von abge- 
stuften Reaktionen — Störungsmeldungen, automatische 
Reduktion von Führungsgrößen, Sperrung aller Energie- 
zufuhr zum Gesamtprozeß, Gefahrenbremse usw.‘— Zur 
Sicherung von Menschenleben und Betriebsmitteln 
bzw. zur Erhöhung der Verfügbarkeit von Anlagen 
durch Betrieb mit automatisch eingeschränkten Figen- 
schaften bis zur Beseitigung der Teilausfälle. 

Die diesem Bericht zugrunde liegenden Arbeiten wur- 
den vom BMFT gefördert (Förderungskennzeichen TV 
8040A). Die Verantwortung liegt jedoch allein heim 
Autor. 
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Dipl.-Ing. Wilfried Heer 


FIO-Baustein erleichtert Prozessor- 
kopplung und Peripherieanschluß 


Multiprozessorsysteme lassen sich durch Zugriff auf 
gemeinsame Speicher verkoppeln. Zu diesem Zweck 
kann man konventionelle Speichersysteme aufbauen 
und mit einer entsprechenden Steuerung ausstatten. 
Inzwischen sind aber die ersten integrierten Bausteine 
verfügbar, mit denen man die Kopplung in Mehrpro- 


1 Mehrprozessor-Systeme 


Der Leistungssteigerung bei Mikrocomputer-Bauele- 
menten steht eine immer höhere Anforderung seitens 
der Anwender gegenüber. Bauelementeleistung ist 
jedoch aus physikalischen Gründen nicht unbegrenzt. 
Weitere Leistungssteigerung wird nur noch durch eine 
Verbesserung der Systemarchitektur möglich sein, z. B. 
durch Parallelverarbeitung, d.h. Mehrprozessor-Sy- 
steme. 

Obwohl die physikalische Leistungsgrenze bei den 

heutigen Mikroprozessor-Bausteinen noch lange nicht 
erreicht ist, sind heute Mehrprozessor-Systeme bereits 
Stand der Technik. Diese Systeme können in zwei Grup- 
pen klassifiziert werden; in 
— festgekoppelte Mehrprozessor-Systeme und 
— lose gekoppelte Mehrprozessor-Systeme. 
Innerhalb dieser Gruppen könnte man noch weiter 
unterteilen, z.B. in Master-Slave-Systeme, homogene 
Systeme, die aus einer Anzahl gleich priorisierter CPUs 
aufgebaut sind, und in Systeme mit Co-Prozessoren für 
spezielle Aufgaben wie z.B. Arithmetik- oder Grafik- 
Prozessoren. 


1.1 Festgekoppelte Mehrprozessor-Systeme 


Festgekoppelte Systeme haben meist einen gemeinsa- 
men Speicher und/oder eine gemeinsame Ein-/Ausgabe 
mit einem gemeinsamen Bus, während die einzelnen 
Prozessoren in diesem System zusätzlich ihren privaten 
Bus mit Speicher und Peripherie besitzen. 

Festgekoppelte Z8000-Systeme können nach dem 
Master-Slave-Prinzip und nach dem Konzept gleichbe- 
rechtigter CPUs aufgebaut sein. Für ein Master-Slave- 
System hat der Z8000 zwei spezielle CPU-Anschlüsse 
(„Multi-Micro In“ und „Multi-Micro Out“) sowie vier 


zessor-Systemen realisieren kann. Weiteres Anwen- 
dungsgebiet solcher Bausteine ist der Anschluß lang- 
samer Peripherie an Mikrocomputer. Im folgenden Bei- 
trag werden Aufbau und Anwendungen des FIO-Bau- 
steins Z8038 aus der 16-Bit-Mikroprozessor-Familie 
Z8000 beschrieben. 


Befehle: „Multi-Micro Request“, „Multi-Micro Set“, 
„Multi-Micro Reset“ und „Multi-Micro Bit-Test“. 

Für ein System mit gleichberechtigten CPUs besitzt 
der Z8000 den „Test and Set“-Befehl, der nicht durch 
einen Bus-Request unterbrechbar ist und ein spezielles 
Statussignal (Z8003/4) ausgibt, das für eine „Bus-Lock“- 
Logik verwendet werden kann. Mit diesem „Test and 
Set“-Befehl kann z.B. ein Semaphore-Byte in einem 
gemeinsamen Speicher abgefragt und gesetzt werden. 


1.2 Lose gekoppelte Mehrprozessor-Systeme 


In einem lose gekoppelten Mehrprozessor-System 
arbeiten alle Prozessoren im System weitgehend unab- 
hängig voneinander. Die Datenübergabe zwischen ein- 
zelnen Prozessoren geschieht über ein E/A-Port, eine 
spezielle Schnittstelle oder über einen Pufferspeicher 
(Dual-Port-RAM). Die Methode der Datenübergabe über 
einen intelligenten Pufferspeicher, wie z.B. dem FIO 
Z8038 von Zilog, ist eine sehr leistungsfähige und ein- 
fach zu realisierende Methode (Bild 2). 


2 FIO Z8038 (,„FIFO Input/Output Interface Unit“) 


Der FIO-Baustein Z8038 ist ein asynchroner FIFO- 
Pufferspeicher für ein Interface zwischen CPU und CPU 
oder CPU und Peripherie. 

Der interne FIFO-Pufferspeicher besitzt eine Kapazität 
von 128 x 8 Bit und kann in der Breite durch Parallel- 
schalten mehrerer FIOs und in der Tiefe durch einen 
speziellen Erweiterungs-Baustein (28060 FIFO), erwei- 
tert werden (Bild 3 und 4). 

An Hand der Blockschaltung (Bild 1) kann man erken- 
nen, daß der FIO Z8038 völlig symmetrisch aufgebaut 
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Schnittstellen, die ein elastisches Interface zwischen 
verschiedenen Mikrocomputern oder Mikrocomputer 
und Peripherie ermöglichen. Zum Beispiel könnte an 
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„Block-Move“-Befehl den internen 
FIFO-Puffer der FIO vollschreibt, während auf der ande- 
ren Seite an Port 2 ein langsames Peripheriegerät, z. B. 


ein Drucker, unabhängig von der 
Geschwindigkeit der CPU Byte 
für Byte aus dem Puffer ausliest 
(Bild 6). 

Als weitere Anwendung könn- 
te z.B. an Port2 eine CPU 
Z8000A und an Port 1 eine CPU 
Z80B angeschlossen werden, die 
beide mit 6 MHz Taktfrequenz ar- 
beiten und völlig asynchron über 
den FIO miteinander kommuni- 
zieren können. 

Der FIO Z8038 unterstützt auch 
den direkten Speicherzugriff 
(DMA) für eine schnelle block- 
weise Datenübertragung von 
Port 1 oder Port 2 in den FIO- 
Speicher oder umgekehrt. 


Port 1 und 2 kann für das Inter-' 
face zwischen CPU und CPU un- 
abhängig vom jeweils anderen 
Port als Schnittstelle im Zeitmul- 
tiplex (Adressen/Daten z.B. Z8, 
Z8000, 8085) oder als multiplex- 
freie Schnittstelle (Z80, 8080, 
6800) programmiert werden. 


An Port 1 muß dabei immer eine CPU angeschlossen 
werden, während Port 2 als Peripherie- oder ebenfalls 
als CPU-Interface dienen kann (Tabelle 1). 

Der interne FIFO-Pufferspeicher ist als Dual-Port- 
RAM aufgebaut, der über einen Schreib- und Lesezähler 
adressiert wird. Diese Technik hat den Vorteil, daß 
jederzeit die Differenz zwischen den gelesenen und 
geschriebenen Bytes die Anzahl der gültigen Datenbytes 
im Speicher angibt. Die Differenz steht im „Byte-Count‘“- 
Register, das von beiden Ports gelesen werden kann. 

Außerdem kann der FIO so programmiert werden, daß 
bei einer bestimmten, frei wählbaren Anzahl von Daten- 
bytes ‘im Puffer ein Interrupt oder ein DMA-Request 
ausgelöst wird. 

Die „Pattern-Match“-Logik löst ebenfalls ein Inter- 
rupt-Request aus, falls ein gelesenes oder geschriebenes 
Byte mit dem Inhalt des „Pattern-Match“-Registers über- 
einstimmt. Somit kann man z. B. beim Übertragen eines 
Datenblocks mit dem End-of-File-(EOF) oder End-of- 
Text-Zeichen (EOT) einen Interrupt auslösen. 

Das Message-Register, das in Wirklichkeit aus zwei 
Registern besteht (Schreiben/Lesen), dient dazu, in 
einem Mehrprozessor-System schnell eine Information 
von einem System an das andere zu übergeben. Bei der 
Übergabe wird gleichzeitig ein Interrupt ausgelöst, der 
dem anderen System das Vorliegen einer Message si- 
gnalisiert. 

Eine solche Information kann z.B. das „End of File“- 
Zeichen oder die Blocklänge eines Datenblocks sein. 


2.1 Interrupt-Struktur des FIO 


Die interne Interrupt-Struktur des FIO besitzt, wie alle 
Peripherie-Bausteine von Zilog, eine Prioritätskette 
(Daisy Chain). Durch die Position innerhalb der Kette 
wird die Priorität jeder Interrupt-Anforde- 
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Tabelle 1. 
Anschlußmöglichkeiten von Port 1 und Port 2 


Port 1 Port 2 Port 1 Port 2 
Program- Program- Anschluß- Anschlußbelegung 
mierung mierung belegung 











(Hard- (Software 

ware) v. Port 1) 

Mı Mo Bı Bo 

00 00 : MPX-Bus, Low Byte 
00 01 il kein Multiplex 

00 1:0 A Byt Drei-Draht-Handshake 
00 4 a ow Byle 7 \yei-Draht-Handshake 
04 00 F MPX-Bus, High Byte 
01 01 usne kein Multiplex 

01 10 High Byte Drei-Draht-Handshake 
0.1 | y!®e Zwei-Draht-Handshake 
10 00 MPX-Bus, Low Byte 

1 0 01 direkter kein Multiplex 

10 1.0 Bus Drei-Draht-Handshake 
1 0 1% Zwei-Draht-Handshake 





Bild 4. Erweiterung des 
FIO-Puffers auf 384 Byte 
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symmetrisch aufgebaut (Bild 6). Wenn Port1 und 2 
jeweils an eine CPU angeschlossen sind, so kann jede 
Seite ihrer CPU bei einem der folgenden Gründe eine 
Interrupt-Anforderung liefern: Schreiben in das Mes- 
sage-Register (Interrupt-Anforderung an die jeweils 
andere CPU), ein Wechsel des Datenflusses durch den 
Puffer, eine Übereinstimmung eines Bit-Musters, das 
Erreichen eines bestimmten Byte-Zählerstandes, ein 
Puffer-Overflow- oder -Underflow-Fehler, Puffer voll 
oder Puffer leer. 

Jede Interrupt-Quelle kann individuell freigegeben 
oder gesperrt werden und hat ihren eigenen Interrupt- 
Vektor. Dieser kann jedoch auch unterdrückt werden, so 
daß bei einem Interrupt-Acknowledge auch ein externes 
Gerät Daten auf den Bus legen kann. 


2.2 FIO im DMA-Betrieb 


Der FIO kann im Multiplex- und im direkten Betrieb 
mit einem DMA-Baustein zusammenarbeiten. Dabei 
unterstützt er zwei Arten der DMA-Übertragung: Das 
„Fly By“ und das sequentielle Übertragen von Bytes. In 
der „Fly By“-Betriebsart wird bei jedem Maschinenzy- 
klus ein Byte vom Speicher in den FIO oder umgekehrt 
übertragen. Bei der sequentiellen Übertragung wird 
während des ersten Maschinenzyklus das Byte vom 
Speicher oder der E/A-Einheit in den DMA-Baustein 
gelesen und beim nächsten Zyklus in den FIO geschrie- 
ben oder umgekehrt. Der DMA-Betrieb kann gleichzeitig 
auf beiden Ports des FIO stattfinden, der DMA-Baustein 
liefert dabei Speicheradressen und Read-/Write-Steuer- 
signale, während der FIO Daten sendet oder empfängt. 
Ein spezielles Statussignal (REQ) gibt im „Fly By“ oder 
im sequentiellen Übertragungsmodus Auskunft über 
den Zustand des FIO-Puffers. 

__Wenn Daten in den FIO geschrieben werden, ist das 
REQ-Signal aktiv, bis der Puffer voll ist. Das REQ-Signal 





bleibt nun inaktiv, bis vom anderen Port der Puffer 
geleert wurde oder die Anzahl der Bytes im Puffer 
kleiner wird, als im „Bytecount“-Register angegeben 
wurde. 

Sollen Daten aus dem FIO gelesen werden, ist das 
REQ-Signal so lange inaktiv, bis vom anderen Port der 
Puffer vollgeschrieben wurde oder die im Byte-Count- 
Register angegebene Zahl überschritten wird. Das REQ- 
Signal bleibt nun so lange aktiv, bis der DMA-Controller 
den Puffer geleert hat. 





3 FIO-gekoppeltes Mehrprozessor-System 


Besonders bei Mehrprozessor-Systemen (Bild 2) 
erweist sich eine Kopplung der einzelnen Systeme über 
ein Dual-Port-RAM wie dem FIO 78038 als einfach zu 
realisierende und sehr effiziente Lösung. Die Bus- 
schnittstelle auf der Seite des Port 1 wird per Hardware 
über die beiden Eingänge M, und M, definiert, die Art 
der Schnittstelle von Port 2 muß von der an Port 1 
angeschlossenen CPU per Befehl festgelegt werden 
(Tabelle 1). So kann z.B. an Port 1 ein Z8001-System 
angeschlossen werden und an Port 2 ein Z80-System 
oder an Port 1 ein Einchip-Mikrocomputer Z8 und an 
Port 2 ein Z8002-System. Die Datenübergabe zwischen 
den Systemen kann über zwei Wege geschehen: Erstens 
über den internen FIFO-Pufferspeicher und zweitens 
über das Message-Register, das den FIFO-Puffer umgeht 
(Bild 1). Zum vollständigen Initialisieren der FIO müs- 
sen die CPUs an beiden Ports die internen Steuerregister 
der FIO (16 auf jeder Seite) beschreiben. Ist eine CPU mit 
Multiplex-Adreß-/Daten-Bus angeschlossen, erfolgen 
Registeradressiertung und Datentransfer in einem 
Zyklus. Bei direktem Bus-Interface ist der Zugriff zu den 
internen Registern eine Operation mit zwei Schritten. 
Mit dem ersten Ausgabe-Befehl der CPU wird ein Zeiger 
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zu dem jeweiligen Register übergeben und mit dem 
zweiten das eigentliche Datum. Das Schreiben und 
Lesen des internen Pufferspeichers ist jedoch immer 
eine Ein-Schritt-Aktion. 
_ In dem System nach Bild 3 kann z. B. der 28002 mit 
einem »schnellen Block-Move-Befehl den FIO-Puffer 
zum Z80-System beschreiben. Ist das Z80-System gerade 
noch nicht bereit, die Daten aus dem FIO abzuholen, 
wird ein „Buffer-Füll“-Interrupt zum Z8002 den Daten- 
transfer stoppen, bis die CPU Z80 den Puffer lesen kann. 
Ist der Puffer leer, wird ein „Buffer-Empty“-Interrupt 
an die CPU Z80 geliefert. Über das Message-Register 
kann dem anderen System z.B. die Länge des Daten- 
blocks, das Ende-Zeichen oder die Zieladresse des 
Datenblocks mitgeteilt werden. 


4 Beispiel: CPU-Drucker-Interface 


Bild 6a zeigt den Anschluß einer schnellen CPU 
Z8002A (6 MHz) an ein langsames Peripheriegerät 
(Drucker). Auf der CPU-Seite ist der FIO an den unteren 
Teil des 16-Bit-Busses (Z-Bus-Low) angeschlossen, wäh- 
rend auf der anderen Seite der Drucker mit einem 3- 
Draht-Handshake-Interface an den FIO angeschlossen 
ist. Die CPU Z8002A kann nun z.B. mit einem Block 
Ausgabe-Befehl (OTIRB = „Output Byte Increment 
Repeat“) mit einer Geschwindigkeit von max. 600 KByte 
pro Sekunde in den FIO-Puffer schreiben. Sobald das 
erste Byte im Puffer steht, zeigt das Signal DAV (‚Data 
Available“) dem Drucker ein gültiges Datenbyte an. 
Signalisiert der Drucker mit seinen Signalen DAC („Data 
Accepted“) und RFD („Ready For Data“), daß er das erste 
Byte übernehmen kann (Bild 6b), wird das erste Byte 
zum Drucker übertragen. 

Da die CPU wesentlich schneller als der Drucker ist, 
wird der Puffer nach kurzer Zeit voll sein. Dabei werden 
die FIO-Signale WAIT und INTERRUPT REQUEST (für 
Puffer voll) aktiviert. Mit dem Interrupt-Request-Signal 








kann in eine Unterbrechungs-Routine verzweigt wer- 
den, die das Schreiben der CPU in den FIO-Puffer stoppt 
und das Bearbeiten anderer Programmteile startet. Hat 
der Drucker den Puffer ausgelesen, wird ein weiterer 
Interrupt-Request („Buffer Empty“) geliefert, der das 
Schreiben von Daten in den FIO-Puffer erneut startet. 
Dadurch ergibt sich eine optimale Ausnutzung der Pro- 
zessorgeschwindigkeit. 


5 Erweiterungsmöglichkeiten des FIO 


Der FIO Z8038 ist dafür ausgelegt, daß er in der Tiefe 
und in der Breite erweitert werden kann. 

Durch einfaches Parallelschalten von mehreren FIOs 
kann der 8-Bit-Datenweg auf 16, 24 oder 32 Bit erweitert 
werden (Bild 3). Durch Beschaltung der Anschlüsse M, 
und M, kann man festlegen, ob z.B. ein FIO an den 
unteren Teil des Z-Busses oder an den oberen Teil 
angeschlossen werden soll. Der FIO am Low-Teil des Z- 
Busses übernimmt dabei immer die Interrupt-Steuerung. 

In der Tiefe kann der 128 Byte große FIO-Puffer durch 
eine Reihenschaltung mit einem FIO-Erweiterungsbau- 
stein (FIFO Z8060) vergrößert werden. 

Dieser 128 Byte große Erweiterungsbaustein ist ein 
nicht intelligenter FIFO-Puffer, der auch alleine ohne 
den FIO Z8038 für eine Ein/Ausgabe-Pufferung benutzt 
werden kann. 

Soll ein FIO, der für eine CPU-CPU-Kopplung vorge- 
sehen ist, erweitert werden, muß an jede CPU ein intelli- 
genter FIO Z8038 angeschlossen werden. 

Zwischen den beiden intelligenten FIOs können nun 
beliebige, nicht intelligente Erweiterungsbausteine 
Z8060 geschaltet werden. Bei einer FIO-Erweiterung, 
die für eine CPU-E/A-Kopplung vorgesehen ist, braucht 
nur die CPU-Serie einen intelligenten FIO Z8038, wäh- 
rend auf der E/A-Seite FIOs Z8060 angeschlossen wer- 
den können (Bild 4). 
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Dipl.-Ing. Werner Handke 


Fehlersuche in Multi-Prozessor-Systemen 


Bei der Fehlersuche in Mehrfach-Prozessor-Syste- 
men wäre es die ideale Lösung, für jeden im System 
vorhandenen Mikroprozessor ein Entwicklungssy- 
stem vorzusehen. Diese Methode ist nicht nur 
redundant, sondern auch kostspielig. Die Benut- 


Anhand des Entwicklungssystems 8550 und des 
Logikanalysators 7D02 von Tektronix soll die Fehler- 
analyse für Mehrprozessorsysteme gezeigt werden. 
Beide Geräte sind direkt für externe Triggerung vor- 
bereitet und stellen damit bereits das wichtigste 
Hilfsmittel für die Fehleranalyse zur Verfügung. 

Während der Fehlersuche wird es selten notwen- 
dig, die Programme beider Mikroprozessoren gleich- 
zeitig zu manipulieren. Im allgemeinen wird ein Pro- 
zessor unabhängig vom anderen soweit als möglich 
programmiert und ausgetestet. Danach wird der 
zweite Prozessor in Betrieb genommen und das 
Zusammenwirken zwischen beiden Systemen beob- 
achtet. Nun wird es wichtig, beide Prozessoren 
bezüglich unsauberer oder fehlerhafter Operationen 
zu überwachen und Unterbrechungspunkte bzw. 
erzwungenes Anhalten für beide Systeme bereitzu- 
stellen. Nur auf diese Weise können fehlerhafte Daten 
und Programmausführung von beiden Systemen 
sorgfältig analysiert werden. 

Im folgenden sind zwei Problemfälle beschrieben, 
die in Multi-Prozessor-Systemen typischerweise auf- 
treten können. An einigen Beispielen wird das 
Zusammenwirken von Entwicklungssystem und 
Logikanalysator beschrieben, um die Fehleranalyse 
betreiben zu können. 


Triggerung von Logikanalysator und 
Entwicklungssystem 


Beim Zusammenwirken des Entwicklungssystems 
mit dem Logikanalysator gibt es zwei Arten zu trig- 
gern: 

- entweder wird das Entwicklungssystem vom Logik- 
analysator getriggert 

-oder das Entwicklungssystem triggert den Logik- 
analysator. 

Zunächst wird die Methode des Triggerns des 
Logikanalysators vom Entwicklungssystem be- 
trachtet. 
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zung bereits vorhandener Laborgeräte erweist sich 
als der praktischere Weg. Als Beispiel seien ein 
Entwicklungssystem und ein Logikanalysator 
genannt, die die notwendigen Debug-Hilfsmittel 
darstellen. 


Triggerung des Logikanalysators vom 
Entwicklungssystem 


An der Rückseite des Entwicklungssystems 8550 
befinden sich zwei Triggerausgänge für externe 
Geräte. Sie sind mit „EVENT 1“ und „EVENT 2“ 
bezeichnet (Bild 1). Falls eines der zugeordneten 
internen Triggerereignisse auftritt, wird am entspre- 
chenden Ausgang ein positiver TTL-Impuls auftre- 
ten. Diese Ausgänge können entweder an die Trigger- 
eingänge (TRIGGER IN) oder an einen oder mehrere 
der Eingangskanäle des Logikanalysators angeschlos- 
sen werden (Bild 2). Mit der beschriebenen Zusam- 
menschaltung kann der Logikanalysator bezüglich 
der vielfältigen Trigger-Kombinationen des Entwick- 
lungssystems getriggert werden. 


Entwicklungssystem vom Logikanalysator getriggert 


Um das Entwicklungssystem mit dem Logikanaly- 
sator zu triggern, wird der Triggerausgang (TRIGGER 
OUT) des Logikanalysators mit irgendeinem Ein- 
gangskanal des Achtkanal-Tastkopfs des Entwick- 
lungssystems verbunden (Bild 3). Das Entwicklungs- 


system kann eingestellt werden, um auf einen oder" 


mehrere Triggerpulse zu reagieren. Zusätzlich sind» 
logische Verknüpfungen des Triggerpulses mit dem 
Auftreten anderer Ereignisse möglich. 


Ergänzend besteht an beiden Systemen die Mög- 


lichkeit, komplexe Triggerbedingungen zu spezifizie- _ 
ren, die bei der Fehlersuche in komplizierten Fällen . 


“ 


erfolgreich sind. Als Beispiel sei der repetierende. 
Fall genannt: Der Logikanalysator triggert das Ent- 
wicklungssystem, welches wiederum den Logikana-- 
lysator triggert usw. 


Beispiel für eine Prozessorschaltung 


Das in Bild 4 gezeigte Schaltungsbeispiel wird für 
die folgende Fehleranalyse herangezogen. Es enthält 


EVENT1 EVENT2 


Eine oder zwei 


Bild +1. Der Logikanalysator wird vom Entwicklungssystem 
getriggert. Es werden die Event-Ausgänge 1 oder 2 mit dem 
TRIGGER IN des 7D02 verbunden 


” 


zwei Prozessoren Z80, beide mit eigenem ROM und 
RAM. Zur Vereinfachung seien identische Adreßbe- 
reiche angenommen. 


ROM 0000...3FFF (alle Adressen sedezimal) 
RAM 4000...4FFF. 


Zusätzlich haben beide Prozessoren zum gemeinsa- 
men RAM im Bereich 5000...5FFF Zugriff. Prozes- 
sor 1 bearbeitet die E/A-Funktionen über die Periphe- 
rie-Baugruppe 1, während Prozessor 2 alle Probleme 
der Datenmanipulation durchführt und sich zur Mas- 
senspeicherung der Peripherie-Baugruppe 2 bedient. 
In diesem Schaltungsbeispiel wird davon ausgegan- 
gen, daß die Prozessoren asynchron über das gemein- 
same RAM kommunizieren, was durch entspre- 
chende Datenworte initiiert wird. Damit sind vielfäl- 
tige Fehlermöglichkeiten gegeben. 


Problemstellung 1 


Während eines Datentransfers von Prozessor 1 zu 
Prozessor 2 gehen einige Byte verloren, wodurch 
Systemfehler hervorgerufen werden. Prozessor 1 
überträgt beispielsweise 16...128 Byte in den gemein- 
samen RAM-Bereich und veranlaßt Prozessor 2 durch 
Interrupt die gespeicherten Daten zu lesen. Die 
Anzahl der gelesenen Daten ist aber geringer als die 
der eingeschriebenen. Wodurch wird nun der Fehler 
verursacht? Durch den Prozessor 1, das RAM oder 
den Prozessor 2? 


Lösung 


Um dieses Problem zu lösen, werden folgende 
Informationen benötigt: 


— Wieviele Daten wurden gesendet? 

— Wie sahen die Daten aus? 

— Wieviele Daten wurden empfangen? 
— Wie sahen die Daten aus? 

Steht für die Problemlösung nur ein Entwicklungs- 
system zur Verfügung, wird es ziemlich schwierig 
sein und mehrere Durchläufe erfordern, zuerst den 
einen Prozessor zu emulieren und dann das Verhal- 
ten des anderen durch Emulation zu analysieren. Die 
Identität der zu vergleichenden Durchläufe wäre 
dabei nicht gewährleistet. Eine Methode zur Fehler- 


Bild 2. Der Logikanalysator wird vom Entwicklungssy- 
stem über einen beliebigen Dateneingang getriggert 





suche wäre, beide Systeme einzusetzen: Mit dem 
Entwicklungssystem wird das Schreiben der Daten in 
das RAM überwacht und aufgezeichnet. Danach wird 
der Logikanalysator getriggert und die Aufzeichnung 
der gelesenen Daten getestet. Die Systemeinstellun- 
gen werden im folgenden beschrieben. 


Einstellung 

Weil das Entwicklungssystem den Logikanalysator 
triggern muß, werden die Systeme, wie in Bild 1 
gezeigt, miteinander verbunden. Der Ausgang EVT2 
wird an den Eingang TRIGGER-IN (extern) des Logik- 
analysators angeschlossen. 

Jetzt muß ein Ereignispunkt des Entwicklungssy- 
stems so gesetzt werden, daß auf jedes Schreiben in 
den gemeinsamen RAM-Bereich ein Trigger ausgelöst 
wird. Dieser Trigger wird als Zählimpuls für einen 
Mehrzweckzähler verwendet. 
> EVT 1CLR A > 4FFF B=MW 


Ereignispunkt 2 muß so definiert werden, daß das 
Ende des Schreibens von Daten erkannt wird. Wird 
das Schreiben beispielsweise mit dem Befehl RET 
(C9) an Adresse 234C beendet, so lautet die Einstel- 
lung für Ereignispunkt 2: 
>EVT2CLR A = 234CB = FD=(C9 

Der Befehl zum Abbrechen der Programmausfüh- 
rung muß mit dem Beenden des Schreibens in den 
RAM-Bereich aktiv werden. 
> BIF ARM 

Der Mehrzweckzähler soll die Ereignisse 1 zählen 
und zeigt damit die Anzahl der geschriebenen Byte: 
>CNT1 

Schließlich wird für den Echtzeit-Speicher des Ent- 
wicklungssystems definiert, nur das Schreiben von 
Daten in das RAM aufzuzeichnen. Es können dann 
maximal 128 Byte aufgezeichnet werden. 
>RTTMW 

Das Entwicklungssystem ist jetzt bereit, festzustel- 
len, wieviele Byte zum Prozessor 2 gesendet worden 
sind, diese in seinem Echtzeit-Speicher aufzuzeich- 
nen und bei Erreichen von Ereignispunkt 2 die Pro- 
grammausführung abzubrechen. Der Logikanalysator 
muß noch eingestellt werden, damit er feststellt, wie- 


viele Daten von Prozessor 2 gelesen werden, und 
muß die Daten in seinem Speicher aufzeichnen. Nach 
dem Lesen aller Daten muß Prozessor 2 angehalten 
werden, um die gespeicherten Daten und den Inhalt 
des gemeinsamen RAM-Bereichs darzustellen. 
Zunächst muß der Analysator 7D02 mit Test 1 so 
eingestellt werden, daß er auf den Triggerimpuls 
EVT2 vom Entwicklungssystem wartet. Beim Emp- 
fangen des Triggers springt der Logikanalysator nach 
Test 2. 
TEST 1 
1IF 
1 WORD RECOGNIZER #1 
1 DATA=XX 
1 ADDRESS=XXXX 
1 RW=X FETCH=X IO/MEM=X INT=X 
1 /INTAK=X EXT TRIG IN=1 
1 TIMING WR=X 
1THEN DO 
1GO TO2 
END TEST 1 
Test 2 überwacht jedes Lesen aus dem gemeinsa- 
men Speicherbereich und inkrementiert bei jedem 
Lesen Zähler 1. Die Speicherauswahl wird gesetzt, 
um alle Daten beim Lesen aus dem gemeinsamen 
RAM in den 256-Worte-Speicher des Logikanalysa- 
tors einzulesen. Als Teil von Test 2 wird der Worter- 
kenner 3 gesetzt, daß er auf das Ende des Lesens aus 
dem RAM triggert, worauf der Logikanalysator den 
Prozessor anhält und die gespeicherten Informatio- 
nen anzeigt: 
TEST 2 
2IF 
2 WORD RECOGNIZER #2 
2 DATA=XX 
2 ADDRESS=5XXX 
2 RIW=1 FETCH=X IO/MEM=0 INT=X 
2 /INTAK=X EXT TRIG IN=X 
2 TIMING WR=X 
2 THEN DO 
2 COUNTNER # 1 0-EVENTS 
2 0-INCREMENT 
2ORIF 
2 WORD RECOGNIZER #3 
2 DATA=C9 
2 ADDRESS=2A43 
2 RIW=X FETCH=1 IO/MEM=X INT=X 
2 /INTAK=X EXT TRIG IN=X 
2 TIMING WR=X 
2 TRIGGER 
2 3-ZERO DELAY 
2 1-SYSTEM UNDER TEST HALT 
2 0-STANDARD CLOCK QUAL. 
END TEST 2 
QUALIFY 
Q STORE ON 
Q WORD RECOGNIZER #2 
Q DATA=XX 
Q ADDRESS=5XXX 
Q R/W=1 FETCH=X IO/MEM=0 INT=X 
Q ANTAK_X EXT TRIG IN=X 
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Q TIMING WR=X 
END QUALIFY 


An dieser Stelle sind beide Prozessoren angehalten 
worden. Der Inhalt des Echtzeit-Speichers enthält die 
letzten 128 Byte, die in den gemeinsamen RAM- 
Bereich geschrieben worden sind, der Mehrzweck- 
zähler enthält die Anzahl der gesendeten Byte. Der 
Speicher des Logikanalysators enthält alle gelesenen 
Byte aus dem gemeinsamen RAM und der Zähler 1 
enthält die Anzahl der gelesenen Byte. Diese Informa- 
tionen können nun ausgewertet werden, um die Zahl 
der verlorenen Byte festzustellen und welche Byte es 
waren. Damit wird die Art des Fehlers offensichtlich 
oder es können Bedingungen gefunden werden, die 
den Fehler verursachen, und deren Ursache kann 
weiterverfolgt werden. 


Problemstellung 2 


Prozessor 1 empfängt Daten von der Peripheriebau- 
gruppe 1. Abhängig von diesen Daten werden vom 
Prozessor 1 verschiedene Aufgaben an Prozessor 2 
gestellt. Während einer bestimmten Folge zweier 
Anfragen werden von Prozessor 2 fehlerhafte Daten 
an Prozessor 1 übertragen, wodurch Prozessor 1 
außer Kontrolle gerät. Das Übertragen von Aufgaben 
an Prozessor 2 erfolgt durch Senden eines eindeuti- 
gen Befehlswortes zusammen mit den benötigten 
Daten. In der fehlerhaften Sequenz überträgt Prozes- 
sor 1 zuerst 2C und einige Datenbyte an Prozessor 2. 
Danach übergibt Prozessor 1 das Befehlswort D1 mit 
dazugehörenden Daten. Während der Bearbeitung 
der zweiten Aufgabe tritt ein Fehler auf und Prozes- 
sor 2 gibt das fehlerhafte Datenpaket an Prozessor 1. 
Der Fehler tritt allerdings nur auf, wenn die beiden 
beschriebenen Aufgaben nacheinander ausgeführt 
werden. Da das Aufeinanderfolgen beider Aufgaben 
zufällig auftritt und nur mit aufwendigen Hilfspro- 
grammen reproduzierbar ist, wird die Fehlersuche 
schwierig sein. 


Lösung 


Der Logikanalysator wird so eingestellt, daß er die 
Folge der beiden beschriebenen Aufgaben feststellt; 
dazu wird seine programmierbare Testmöglichkeit 
benutzt. Wenn dieses Ereignis eintritt, soll der Logik= 
analysator die Daten der Ausführung des zweiten 





Bild 3. Das Entwicklungssystem 8550 wird vom Logikanalysator 
getriggert. TRIGGER OUT wird mit einem der Dateneingänge des 
Achtkanal-Testkopfs des 8550 verbunden 


Programms aufzeichnen, und auf das Schreiben des 
fehlerhaften Datenpakets in das gemeinsame RAM 
warten. Damit wird das Entwicklungssystem, das die 
geschriebenen Daten aufzeichnet, getriggert. Auf 
diese Weise werden die Programmausführung und 
Ergebnisdaten darstellbar und damit die notwendige 
‚Information geliefert, um den Fehler zu finden. 


Einstellungen 

Damit der Logikanalysator das Entwicklungssy- 
stem triggern kann, müssen die Systeme so zusam- 
mengeschaltet werden, wie es in Bild 3 dargestellt ist. 
Der externe Triggerausgang des Logikanalysators 
wird an den ersten Kanal des Logiktastkopfes des 
"Entwicklungssystems angeschlossen. Der Analysator 
‚’D02, der für dieses Anwendungsbeispiel benutzt 
werden soll, ist nicht mit einer Zeitgeberfunktion 
(Timing-Option) ausgerüstet, deshalb gibt der externe 
Triggerausgang immer ein Triggersignal ab, wenn 
eine Triggerbedingung erfüllt ist. 

Um dieses Problem zu lösen, muß der Logikanaly- 
sator so eingestellt werden, daß er die fehlerhafte 
Befehlsfolge erkennt. Weil diese Anforderungen in 
dem gemeinsamen RAM-Bereich nicht unter festen 
Adressen abgelegt werden, ist ihre Identifizierung 
beim Lesen fast unmöglich. Die Anforderungen wer- 
den allerdings vor ihrer Bearbeitung in einem festge- 
legten Speicherbereich des internen RAM zwischen- 
gespeichert. Deshalb kann dieser Speicherbereich 
beobachtet werden, und das Auftreten der Befehlsfol- 
gen kann bei deren Einschreiben in den Speicher 
erkannt werden. 


Um dies mit dem Logikanalysator durchzuführen, 
muß Test 1 die erste Anforderung (Befehl 2C) erken- 
nen. Diese Anforderung wird an Adresse 4500 zwi- 
schengespeichert. 


1 IF TEST 1 
1 WORD RECOGNIZER #1 
1 DATA=2C 
1 ADDRESS=4500 
1 R/W = 0 FETCH=X IO/MEM=0 INT=X 
1 ANTAK_=EXT TRIG IN=X 
1 THEN DO 
1GOTO2 

END TEST 1 

Test 2 erkennt, wenn in den Zwischenspeicher an 
Adresse 4500 das Byte D1 geschrieben wird. Falls das 
geschieht, springt das System zu Test 3, wodurch das 
Aufzeichnen von Daten beginnen wird. Es muß 
zusätzlich der Fall betrachtet werden, wo zwei auf- 
einanderfolgende 2C-Anforderungen auftreten. Falls 
dies eintritt, muß das System in Test 2 bleiben und 
nicht nach Test 1 zurückspringen. Sollte allerdings 
das nächste Datenwort, geschrieben an Adresse 4500, 
nicht D1 oder 2C sein, muß das System nach Test 1 
zurückspringen. 


TEST 2 
2IF 
2 WORD RECOGNIZER #2 


2 DATA=D1 
2 ADDRESS=4500 
2 RIW=0 FETCH=X IO/MEM=0 INT=X 
2 /INTAK=X EXT TRIG IN=X 
2THEN DO 
2 GO TO 3 
2 OR IF 
2 WORD RECOGNIZER # 
2 DATA=2C 
2 ADDRESS=4500 
2 VW=0 FETCH=X IO/MEM=0 INT=X 
2 INTAK=X EXT TRIG IN=X 
2THEN DO 
2GOTO2 
2OR IF 
2 WORD RECOGNIZER #3 
2 DATA=XX 
2 ADDRESS=4500 
2 VW=0 FETCH=X IO/MEM=0 INT=X 
2 AINTAK=X EXT TRIG IN=X 
2THEN 
2GO TOı 
END TEST 2 


Test 3 veranlaßt den Logikanalysator die nächsten 
256 Befehle aufzuzeichnen, die von Prozessor 2 aus- 
geführt werden. Die Aufzeichnung wird beendet, 
wenn das mit dem Worterkenner 3 bezeichnete 
Wort auftritt. Falls vorher die 256-Byte-Grenze 
erreicht wird, springt das System nach Test 4, wo auf 
das Ende des angeforderten Programms gewartet 
wird, bevor das Entwicklungssystem getriggert wird. 


TEST 3 
3IF 

3 COUNTER #1 = 256 0-EVENTS 
3THEN 

3GO TO4 

30R IF 

3 WORD RECOGNIZER #4 

3 DATA=C9 

3 ADDRESS=2E20 

3 RW=X FETCH=1 IO/MEM=X INT=X 
3 /INTAK=X EXT TRIG IN=X 

3THEN 

3 TRIGGER 

3  3-ZERO DELAY 

3 _ 0-SYSTEM UNDER TEST CONT. 
3 _ 0-STANDARD CLOCK QUAL. 
3ELSE 

3 

3 COUNTER # 1 0-EVENTS 

3  0-INCREMENT 

3 QUALIFY 


3 
END TEST 3 


Mit Test 4 erwartet der Worterkenner 4 den Return- 
Befehl auf Adresse 2E20, womit das Ende der Routine 
angezeigt wird, bevor das Schreiben im gemeinsamen 
RAM beginnt. Nachdem alle Daten ins RAM geschrie- 
ben sind, triggert der Logikanalysator das Entwick- 
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lungssystem, um die Daten aufzeichnen zu können, 
die nun aus dem gemeinsamen RAM gelesen werden. 


TEST 4 

4lF 

4 WORD RECOGNIZER #4 

4 DATA=C9 

4 ADDRESS=2E20 

4 RIW=X FETCH=1 IO/MEM=X INT=X 

4 /INTAK=X EXT TRIG IN=X 

4THEN DO 

4 TRIGGER 

4 3-ZERO DELAY 

4 0-SYSTEM UNDER TEST CONT. 

4 0-STANDARD CLOCK QUAL. 
END TEST 4 


Das Entwicklungssystem muß auf die vom Logik- 
analysator gesendeten Trigger reagieren, um die von 
Prozessor 2 gesendeten Daten aufzeichnen zu kön- 
nen. Dazu wird EVENT 1 gesetzt, um das Triggersi- 
gnal zu erkennen. Das Triggersignal wird am Kanal 1 
des externen Tastkopfes am Entwicklungssystem ein- 
gespeist. 
>EVT 1 CLR T=1xxxxxxx 


EVENT 2 muß so eingestellt werden, daß Prozes- 
sor1 angehalten wird, wenn das Lesen aus dem 
gemeinsamen RAM beendet wird. Die Lese-Routine 
endet, wenn an Adresse 2EC4 der Return-Befehl 
steht: 
>EVT 2 CLR A=2EC4 D=(C9 B=F 

Um den Prozessor 1 mit EVENT 2 anzuhalten, wird 
der BREAK-IF-Befehl benutzt. Weil weiterhin Prozes- 
sor 1 nur angehalten werden soll, wenn EVENT 2 
nach EVENT 1 auftritt, wird die ARM-Bedingung er- 
forderlich. 
> BIF ARM 

Wie Prozessor 2 schreibt der Prozessor 1 alle vom 
gemeinsamen RAM gelesenen Daten in einen inter- 
nen Zwischenspeicher. Deshalb wird das Entwick- 
lungssystem veranlaßt, nur das Schreiben zum Spei- 
cher (Memory Writes) aufzuzeichnen. Damit werden 
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die 128 letzten Byte erfaßt, die von Prozessor 2 gesen- 
det worden sind. 


>RTTMW 


Wenn das gesamte Programm ausgeführt wird, 
wird nach Ausführung der Befehlsfolgen, die durch 
die Anforderungen 2C und D1 aufgerufen wurden, 
der Logikanalysator das Entwicklungssystem triggern 
und selbst die letzten 256 Befehle der nachfolgenden 
Routine aufzeichnen. Das Entwicklungssystem zeich- 
net die 128 Byte auf, die vom Prozessor 2 gesendet 
werden. Durch die Anwendung von Entwicklungssy- 
stem und Logikanalysator in gemeinsamem Einsatz 
können signifikante Daten von beiden Prozessoren 
aufgezeichnet werden und damit können Systemfeh- 
ler gefunden werden. Wird nur eines der Hilfsmittel 
eingesetzt, und korrespondierende Daten in verschie- 
denen Meßdurchgängen ermittelt, besteht keine 
Sicherheit, daß in den verschiedenen Meßdurchgän- 
gen identische Fehler analysiert werden. 


Mit den beschriebenen Meßmethoden können mit 
Entwicklungssystem und Logikanalysator, die sich 
wie das 8550 und der 7D02 ergänzen, komplizierteste 
Vorgänge in Multiprozessor-Schaltkreisen untersucht 
werden. Es gibt noch eine Reihe weiterer Anwendun- 
gen. Ein Beispiel wäre, mit dem Entwicklungssystem 
den Logikanalysator zu triggern und asynchron zeit- 
kritisches Zusammenwirken von Baugruppen zu te- 
sten. 
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Variables Testkonzept 
für Mikroprozessorsysteme 


Immer mehr Mikroprozessoren werden in mittleren 
oder großen Rechensystemen eingesetzt. Dabei 
wird es für den Benutzer immer wichtiger, fast zu 
jedem Zeitpunkt zu wissen, ob das System noch 
korrekt arbeitet. Da eine On-line-Fehlererkennung 
im laufenden Betrieb sehr aufwendig ist, begnügt 
man sich in unkritischen Anwendungen damit, den 
Rechner nach dem Systemstart, in festen Zeitinter- 
vallen oder in Leerzeiten zu testen. Nur die Daten- 
wege und der Speicher werden on-line durch fehler- 


1 Konzept des Testprozessors 


Das Testsystem sieht vor, auf jedem Prozessorchip 
einen zusätzlichen Testprozessor zu integrieren. In 
Einprozessorsystemen übernimmt er die Steuerung 
des gesamten Systemtests. In Mehrprozessorsyste- 
men wird ein Prozessor als Serviceprozessor ausge- 
legt. Dieser ist mit den Testprozessoren in den ande- 
ren Funktionsprozessoren über ein eigenes Kommu- 
nikationsnetz verbunden (Bild 1). Dadurch entsteht 
ein mächtiges hierarchisches Testsystem. 


Der Testprozessor auf dem Chip übt sowohl reine 
Schaltfunktionen als auch Kontrollfunktionen aus. 
Der Serviceprozessor in einem Multiprozessorsystem 
übt die gleichen Funktionen aus, wie sie heute bei 
entsprechenden Prozessoren in Großrechnern üblich 
sind. Mit dem Testprozessor auf dem Prozessorchip 
und dem Serviceprozessor läßt sich ein dreistufiges 
Testkonzept verwirklichen: 


— Auf der untersten Ebene testet sich der Testprozes- 
sor so gut wie möglich selbst und testet den Test- 
kern im Funktionsprozessor, der für einen Prozes- 
sor-Selbsttest im Bootstrapping-Verfahren notwen- 
dig ist [1,2]. Um einige Komponenten des Test- 
kerns zu testen, verwendet der Testprozessor auch 
spezielle Testschaltungen (siehe Abschnitt 3). 

— Auf der zweiten Ebene testet sich jeder Funktions- 
prozessor selbst. Dieser Selbsttest mit Hilfe von 
Mikroprogrammen wird nach dem Bootstrapping- 


erkennende (oder -korrigierende) Codes (Parity, 
Hamming usw.) überprüft. — Im folgenden wird ein 
Konzept für ein variables Diagnosesystem in Ein- 
und Mehrprozessorsystemen vorgestellt. Dabei 
wird angenommen, daß das Rechensystem aus 
einem oder mehreren Mikroprozessoren des glei- 
chen Typs aufgebaut ist. Die Prozessoren sind 
durch einen gemeinsamen Systembus miteinander 
verbunden. Die Prozessoren haben eine Wortlänge 
von 16 oder 32 Bit und sind mikroprogrammiiert. 


Verfahren durchgeführt. Die Kontrolle über den 
Selbsttest und die Auswertung der Testergebnisse 
übernimmt der zugehörige Testprozessor. 


— Auf der dritten Ebene übernimmt der Servicepro- 
zessor in Multiprozessorsystemen die Koordination 
für einen Gesamttest. Er testet das Kommunika- 
tionsnetz zwischen den Testprozessoren (damit 
auch jeden einzelnen Testprozessor selbst) und die 
Komponenten des Systems, die sich nicht selbst 
testen können (Hauptspeicher, System-Bus usw.). 
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Bild 1. Testprozessoren und Serviceprozessor in einem Mehrpro- 
zessorsystem (TP = Testprozessor) 
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Im Falle eines Fehlers kann er zusammen mit dem 
Betriebssystem bei entsprechend vorhandener 
Redundanz eine Rekonfiguration durchführen. 


2 Funktionen des Test- und des 
Serviceprozessors 


Der Testprozessor auf dem Chip übt sowohl reine 
Schaltfunktionen als auch Steueraufgaben aus. Die 
wesentlichen Funktionen davon sind: 

— Initialisierungs- und Wartungsfunktionen: 

Der Testprozessor macht nichtzugängliche Teile 

des Prozessors (Register, Statusflags usw.) von 

außen zugänglich. Damit erlaubt er, einen definier- 
ten Anfangszustand im Prozessor zu erzeugen, den 

Prozessor einschließlich des Mikrocontrollers in 

einen bestimmten Zustand zu bringen und sämtli- 

che Register und Flags einzeln zu setzen und zu 
lesen. 
— Kontrollfunktionen: 

Er überwacht die Mikroprogrammadressen und die 

Ausführungszeiten von Diagnoseprogrammen, die 

auf dem Prozessor ablaufen. Er wertet die Meldun- 

gen spezieller Prüflogiken aus, welche on-line die 
externen Datenwege und den Hauptspeicher über- 
wachen und reagiert auf Fehler z. B. durch Ansto- 

Ben einer Befehlswiederholung oder mit einem Pro- 

zessor-Stopp. 

— Ausführen und Steuern von Prüfprogrammen: 

Der Testprozessor testet sich in einem Grundtest 

soweit wie möglich selbst sowie den Testkern des 

Funktionsprozessors. Außerdem übernimmt er die 

Auswertung der Ergebnisse des Prozessor-Selbst- 

tests. 

Der Serviceprozessor übt Funktionen aus, wie sie 
heute bei entsprechenden Prozessoren in Großrech- 
nern üblich sind. Dazu gehören: 

— Systeminitialisierung: 

Zunächst wird vom Serviceprozessor eine Grund- 

prüfung aller Komponenten des Gesamtsystems 

durchgeführt. Im Fehlerfalle erfolgt gegebenenfalls 
eine Rekonfiguration. Anschließend wird das 

Laden des Betriebssystems angestoßen. 


— Unterstützen des Betriebssystems 
im Falle einer Störung: 
Der Serviceprozessor unterstützt das Betriebssy- 
stem im Falle einer durch Befehlswiederholung 
bzw. Speicherkorrektur nicht zu beseitigenden Stö- 
rung bei der Rekonfiguration, wenn entsprechende 
Redundanz vorhanden ist. 


— Ausführen von Prüfprogrammen: 
Der Serviceprozessor führt Prüfprogramme für den 
Arbeitsspeicher, das Unterbrechungssystem und 
andere Komponenten aus, die sich nicht selbst 
testen können. Er stößt den Testvorgang in den 
anderen Funktionsprozessoren an und wertet die 
Ergebnisse aus. 

— Fehleranalyse: 
Im Serviceprozessor wird der von ihm bei Auftre- 
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ten eines sporadischen oder festen Fehlers gesi- 
cherte Zustand einer Systemkomponente ausgewer- 
tet und — soweit notwendig - eine Fehlerlokalisie- 
rung durchgeführt. Außerdem führt er Fehlerstati- 
stiken. 

— Bereitstellen von Wartungsfeldroutinen: 
Der Serviceprozessor soll das herkömmliche War- 
tungsfeld bei Großrechnern ersetzen. Die Wartungs- 
feld-Zugriffe (z. B. Anzeige von Speicherinhalten, 
Anzeige und Setzen von Registern in den einzelnen 
Prozessoren, Einzelbefehlsausführung usw.) wer- 
den von Serviceprozessor-Routinen durchgeführt. 

— Konsolbedienung: 
Der Serviceprozessor übernimmt die Aufgabe der 
Konsolsteuerung und bedient — transparent für das 
Betriebssystem — die Konsole. Dabei steuert er den 
Datenverkehr. 

— Weitere Serviceprozessor-Dienste: 
Der Serviceprozessor sollte zusätzlich einige 
Dienstprogramme anbieten, z. B. für Speicherabzug 
usw. 


3 Testprozessor und Prozessor-,Selbsttest‘“ 


Ein wesentlicher Teil im Testkonzept ist der Pro- 
zessor-Selbsttest mit Hilfe von Mikroprogrammen 
und zusätzlicher Testlogik nach dem Bootstrapping- 
Verfahren. Bei einem Selbsttest nach dem Bootstrap- 
ping-Verfahren [1, 2] wird zunächst der gesamte Pro- 
zessor in einzelne Testobjekte zerlegt und ein Test- 
kern definiert. Unter dem Testkern werden alle die 
Komponenten des Prozessors verstanden, die zum 
Testen des ersten Testobjektes notwendig sind. Er 
soll möglichst minimal sein, da seine Komponenten 
als fehlerfrei vorausgesetzt bzw. von „außen“ getestet 
werden müssen. Ausgehend von diesem Testkern 
werden Schritt für Schritt die übrigen Testobjekte 
überprüft. Zum Überprüfen einer Komponente wer- 
den jeweils nur im bisherigen Ablauf getestete Kom- 
ponenten benutzt. 


Bei einem Selbsttest mit Hilfe von Mikroprogram- 
men besteht der Testkern aus dem Steuerwerk, d.h. 
der Mikroprogramm-Kontrolleinheit, dem Mikropro- 
grammspeicher und dem Pipeline-Register. Hinzu 
kommen noch das Makro-Befehlsregister und das 
„Mapping-PROM“, da diese beiden Komponenten 
nicht vom Prozessor selbst mit Mikroprogrammen 
getestet werden können (Bild 2). Dieser Testkern soll 
nun als erstes mit Hilfe des Testprozessors ünd 
zusätzlicher Testlogik für eine Signaturanälyse über- 
prüft werden. Anschließend kann sich der ei 
vollständig selbst testen. > 


Der Test des Mikroprogrammspeichers (ROM) Pe 
des Pipeline-Registers erfolgt mit Hilfe der Signatur- 
analyse [3]. An zusätzlicher Hardware ist ein Zähler ‘ 
(mit Null-Erkennung) am Adreßeingang des Spei- 
chers notwendig. Das Pipeline-Register kann als 
rückgekoppeltes Schieberegister aufgebaut und damit 
als Signaturregister eingesetzt werden [3]. Der Test- 
prozessor setzt den Zähler am Testanfang, steuert den 
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Bild 2. Test eines mikroprogrammierten Steuerwerkes 





Multiplexer zwischen Zähler und Mikrokontroller, 
stellt das Signaturregister auf einen bestimmten 
Anfangswert ein und wertet das Ergebnis im Signa- 
turregister aus. Solch ein Test überprüft sowohl den 
Inhalt des Speichers als auch die Adreßlogik. 


Eine Mikroprogramm-Kontrolleinheit in der Kom- 
plexität eines AM 2910 hat zum Beispiel 20 Eingänge 
und 16 Ausgänge. Sie kann vom Testprozessor durch 
Anlegen von Testmustern an die Eingänge und durch 
Auswerten der Ausgänge getestet werden. Dazu soll- 
ten alle Ein- bzw. Ausgänge an jeweils einem Schie- 
beregister hängen, das vom Testprozessor seriell gela- 
den bzw. gelesen werden kann. 


Testmuster und Soll-Ergebnisse können wahr- 
scheinlich nicht auf dem Chip gehalten werden. 
Wegen der geringen Komplexität des Controllers (nur 


16 Befehle) lassen sie sich eventuell algorithmisch 
vom Testprozessor erzeugen. Ansonsten müssen sie 
jeweils von außen über die serielle Schnittstelle, die 
der Testprozessor zur Verbindung mit einem Service- 
prozessor hat, geladen werden. 


Makro-Befehlsregister und Mapping-PROM lassen 
sich wiederum mit Hilfe der Signaturanalyse testen. 
Wegen der geringen Breite des Eingangs (8-Bit-Op- 
code) kann die Funktion des Zählers als Stimuli 
eventuell auch vom Testprozessor übernommen wer- 
den. Das Schieberegister zwischen Mapping-PROM 
und Mikrocontroller wird so aufgebaut, daß es als 
Signaturregister verwendbar ist. Bild 2 verdeutlicht 
noch einmal die zusätzliche Testlogik und die Ver- 
bindungen zum Testprozessor, die für das Überprü- 
fen des Steuerwerkes notwendig sind. 


Nachdem der Testkern des Funktionsprozessors 
durch den Testprozessor überprüft wurde, kann sich 
nun der Prozessor mit Hilfe von Mikro-Diagnosepro- 
grammen, die im ROM abgespeichert sind, selbst 
testen. Die Ergebnisse des Prozessor-Selbsttests kön- 
nen in einem Statusregister, welches als erstes 
Testobjekt überprüft werden muß, abgelegt werden. 
Der Testprozessor kann den Inhalt dieses Statusregi- 
sters nach außen weiterleiten. 


4 Ergebnisse 


Die Komplexität des Testprozessors ist gegenüber 
der des eigentlichen Funktionsprozessors relativ 
gering. Erste Abschätzungen ergaben einen Befehls- 
satz von 40...50 Befehlen, eine Wortbreite von 8 Bit, 
256 Worte ROM und 16 Worte RAM. Für die Kommu- 
nikationsschnittstelle zum Serviceprozessor sind ca. 
10...15 zusätzliche Anschlüsse am Prozessorchip er- 


forderlich. 
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Busvergabe durch dezentralen Arbiter 


Ein wichtiger Gesichtspunkt beim Entwurf von Mi- 
kroprozessorsystemen ist die Kapazität des Bus- 
systems. Beikomplexeren, stark gekoppelten Syste- 
men, die aus einer großen Zahl von Einzelprozesso- 
ren bestehen, reicht ein einzelner Bus zur Bewälti- 


1 Konzepte 


Mikroprozessoren lassen sich auf unterschiedliche 
Art zu einem Multiprozessorsystem zusammenfassen, 
beispielsweise indem verschiedene Spezialprozesso- 
ren untereinander verbunden werden, die so die 
Funktion eines konventionellen Rechners erfüllen. 
Ein anders geartetes System läßt sich durch einen 
vollständig symmetrischen Verbund von gleicharti- 
gen Prozessoren realisieren. Diese Architektur eignet 
sich vor allem, um anfallende Aufgaben auf die ein- 
zelnen Prozessoren zu verteilen und parallel zu verar- 
beiten. Mit solchen Systemen lassen sich große Re- 
chenkapazitäten erre ıen; dies gest ıttet es, etwa in 
der Prozeßdatenverarbeitung, aufwendige Hardware 
durch Software zu ersetzen. Man erreicht eine sehr 
hohe Anpassungsfähigkeit an verschiedenste Proble- 
me. Wachsende Softwareanforderungen lassen sich 
durch eine größere Anzahl von Prozessprmoduln aus- 
gleichen. Dabei muß aber auch das Bussystem, das alle 
Moduln verbindet, den erhöhten Ansprüchen ent- 
sprechend erweitert werden können. 

In lose gekoppelten Multiprozessorsystemen ver- 
mag meist ein einzelner Bus den Datentransfer zu be- 
wältigen. Bei der Realisierung größerer, stark gekop- 
pelter Systeme hingegen ist die Bereitstellung von 
ausreichenden Kommunikationsmöglichkeiten ein 
zentrales Problem. Stark gekoppelte Systeme sind 
durch einen intensiven Datenfluß gekennzeichnet, 
z. B. zwischen den einzelnen Prozessoren sowie Zwi- 
schen Prozessoren und wechselseitig benutzten ge- 
meinsamen Speichern und anderen Systemteilen. 

Hier sind Bussysteme erforderlich, die eine gleich- 
zeitige Datenübertragung auf mehreren unabhängigen 
Einzelbussen erlauben. Aus ökonomischen Gründen 
muß in der Regel jeder Einzelbus von jedem der asyn- 
chron arbeitenden Prozessoren benutzt werden kön- 
nen. Die Verwaltung solcher Mehrfach-Busstruktu- 
ren, d.h. die Vergabe von freien Bussen an anfor- 
dernde Prozessoren nach gewissen Kriterien, ist des- 
halb eine wesentliche Aufgabe innerhalb von Multi- 
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gung der anfallenden Datentransfers nicht aus. 
Daher müssen andere Lösungen angestrebt wer- 
den. Beispiel dafür ist ein nicht beschränktes Bus- 
system mit der hier beschriebenen fairen Busver- 
gabe durch einen dezentralen, parallelen Arbiter. 


prozessor-Systemen; die Art ihrer Realisierung beein- 
flußt die Systemeffizienz in der Regel stark. 
Symmetrische Multiprozessorsysteme bieten sich 
für eine dezentrale Hard- und Software-Organisation 
an; selbst traditionell zentrale Systemteile wie das Be- 
triebssystem können dezentralisiert und so angelegt 
werden, daß ihnen die aktuelle Zahl benutzbarer Mo- 
duln, Busse usw. unbekannt ist. Fallen einzelne Kom- 
ponenten aus, werden sie routinemäßig nicht mehr 


Prozessor Prozessor 


Prozessor 


q 
Prozessor 


Busstrukturen fürsymmetrische Systeme: a) Common-Bus, 
b) Multi-Common-Bus, c) Crossbar-Switch (Kreuzschie- 
nenverteiler) 





verwendet; dies beeinträchtigt die Systemeffizienz 
wenig. 

Diesen beiden Anforderungen, nämlich Flexibilität 
und Fehlertoleranz, muß auch das Bussystem genü- 
gen. 


2 Bussysteme 


Die am häufigsten vorgeschlagenen und zum Teil 
‚realisierten Busstrukturen für symmetrische Systeme 
sind der übliche Common-Bus, der Multi-Common- 
Bus und der Crossbar-Switch (Bild). 

Der Common-Bus ist ein einzelner Bus, der keine 
parallelen -Datentransfers gestattet; er erfüllt beide 
oben genannten Bedingungen nicht. 

Nach dem Prinzip des Kreuzschienenverteilers 
(Crossbar-Switch) lassen sich aktive und passive Mo- 

„duln wie z. B. Prozessoren und Speicher miteinander 
verbinden. Die Kapazität eines solchen Systems ist 
‘sehr groß, da eine Verbindung zu einem freien Modul 
immer möglich ist, unabhängig von den parallel dazu 
stattfindenden Kommunikationen. Es ist jedoch nur 
mit großem Aufwand zu erweitern, und zudem ist 
seine Fehlertoleranz gering, da jeweils zwei Moduln 
nur über einen einzigen Weg miteinander kommuni- 
zieren können. 

Beim Multi-Common-Bus besitzen alle Moduln ei- 
nen eigenen Bus; diese einzelnen Busse werden durch 
eine beliebige Anzahl von parallelen Bussen unter- 
einander verbunden. Ein Datentransfer führt also über 
die zwei Modulbusse und einen der verbindenden 
Datenbusse. 

Verbindungen sind zwischen allen Moduln in glei- 
cher Weise möglich; es existieren jedoch mehrere 
Wege über die parallelen Datenbusse. Defekte Bus- 
schalter können darum umgangen werden; dies führt 
zu einer hohen Fehlertoleranz. 

Bei geeigneter Architektur ist die Zahl der Daten- 
busse nicht beschränkt. Es lassen sich beliebige Bus- 
kapazitäten verwirklichen. 


3 Bus-Arbitration 

In einem Multiprozessorsystem mit einem Multi- 
Common-Bus wird man die Anzahl der Datenbusse 
nur so groß wählen, daß die Leistungsfähigkeit des 
Rechnersystems im Mittel nicht durch die Buskapazi- 
tät beschränkt wird. Ein freier Bus kann deshalb von 
einem Prozessor nicht direkt, sondern erst nach An- 
forderung und Zuteilung belegt werden. In jedem ge- 
bräuchlichen Rechnersystem wird diese Aufgabe von 
einem Bus-Arbiter übernommen, der anhand geeigne- 
ter Kriterien von allen Anforderungen eine auswählt. 
Bei einem Multi-Common-Bus ist zusätzlich eine 
Auswahl eines freien Busses notwendig. 

Ein zentraler Bus-Arbiter, der wie in Einzelbus-Sy- 
stemen die Anforderungen seriell bearbeitet, läßt sich 
auch für den Multi-Common-Bus ohne Schwierigkei- 
ten realisieren: Jeder Prozessor meldet etwa über eine 
eigene Leitung einer Busvergabelogik die Priorität 
seiner Anforderung. Von allen Prozessoren mit der 
höchsten Priorität wählt der Arbiter einen beliebigen 
aus und teilt diesem den ersten freien Bus zu. Nun 
wird mit dem nächsten freien Bus genauso verfahren. 
Die Nachteile dieses Verfahrens liegen auf der Hand: 


® Das System kann nur umständlich erweitert wer- 
den, da jeder Teilnehmer separat an den Arbiter an- 
geschlossen wird. 

® Das System ist fehleranfällig: ein Defekt im Arbiter 
hat fatale Folgen. 

® Die Buskapazität ist stark begrenzt: nach einer be- 
stimmten Anzahl von Buszuteilungen wird ein ver- 
gebener Bus wieder frei und muß erneut verwaltet 
werden. Damit ist die Grenze erreicht; mehr Busse 
können mit diesem Prinzip nicht sinnvoll genutzt 
werden. 

Bei den üblichen Busvergabe-Methoden gibt es zu- 
dem keine völlig gleichberechtigten Moduln. Bei 
mehreren Anforderungen mit der gleichen Priorität 
wird diejenige bevorzugt, welche am nächsten beim 
Arbiter liegt. Dies kann dazu führen, daß ein Modul 
mit einer hohen Anforderungsrate alle Komponenten 
blockiert, die weiter vom Arbiter entfernt sind. Ein 
solches Busvergabe-Verfahren erfüllt nicht die An- 
sprüche, die an den Bus eines großen Multiprozessor- 
systems gestellt werden; dies gilt ebenfalls für die an- 
deren, bisher realisierten Busvergabe-Prinzipien. 

Das hier beschriebene Arbitrierungs-Verfahren 
weist folgende Eigenschaften auf: 
© Die gesamte Vergabe-Logik ist vollständig dezentral 

aufgebaut und damit fehlertolerant. Der Ausfall ein- 
zelner Komponenten führt dazu, daß entweder ein- 
zelne Kreuzungspunkte oder schlimmstenfalls ein- 
zelne Moduln bzw. Datenbusse unbenutzbar wer- 
den. Dies führt nur zu einer geringfügigen Verlang- 
samung des Systems. 


@ Die Bus-Arbitrierung ist so strukturiert, daß sowohl 
die Zahl der angeschlossenen Moduln, als auch die 
Zahl der verwendeten Datenbusse nicht beschränkt 
ist; die Busvergabe-Logik ist in beiden Richtungen 
kaskadierbar und damit sehr flexibel. 

® Busanforderungen werden nach Prioritäten bear- 
beitet. Dies ermöglicht kurze Zugriffszeiten bei 
Echtzeitanwendungen bei gleichzeitiger ökonomi- 
scher Dimensionierung des Bussystems. 

@ Busanforderungen gleicher Prioritäten werden fair, 
d. h. ohne jede Bevorzugung bearbeitet. 

@ Die Busvergabe erfolgt sehr schnell: Die Zeit zwi- 
schen einer Busanforderung hoher Priorität und der 
Zuteilung eines freien Busses liegt typisch zwi- 
schen 0 und 100 ns; innerhalb von 200 ns können 
beliebig viele Busse vergeben werden. 


4 Realisierung einer dezentralen, 
parallelen Bus-Arbitration 


Die oben diskutierten Eigenschaften lassen sich mit 
folgendem Prinzip der Bus-Arbitrierung erzielen: Auf 
jedem freien Datenbus zirkuliert völlig unabhängig 
ein Zuteilungssignal; es startet am Busanfang und 
passiert sämtliche Kreuzungspunkte des Datenbusses 
mit den Modulbussen. Wenn das Signal am Ende an- 
gekommen ist, wird es erneut gestartet. 

Falls ein Modul einen Datenbus benutzen will, er- 
zeugt es auf dem Modulbus, und damit an allen Kreu- 
zungspunkten, ein Anforderungssignal. Dieses Signal 
hält die nächste Flanke des Zuteilungssignals auf ei- 
nem beliebigen freien Datenbus auf; dieser betreffende 
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Bus kann nun nicht mehr anderweitig vergeben wer- 
den. Unmittelbar nach Eintreffen der Flanke wird das 
Anforderungssignal zurückgenommen, so daß alle 
folgenden Zuteilungssignale von anderen freien Bus- 
sen den entsprechenden Modulbus passieren können. 


Folgen jedoch zufällig einige Zuteilungssignale 
sehr dicht aufeinander, so können mehrere am Mo- 
dulbus festgehalten werden. Von den entsprechenden 
Datenbussen wird einer durch die modulinterne Mo- 
dulbus-Arbitrierung ausgewählt; die übrigen werden 
sofort wieder freigegeben. 


Nach beendetem Datentransfer läuft das Zutei- 
lungssignal weiter über die restlichen Kreuzungs- 
punkte und zirkuliert von neuem, bis es durch eine 
Zuteilung erneut festgehalten wird. 


Die für jeden Kreuzungspunkt erforderliche Logik 
ist sehr einfach und so ausgelegt, daß sie sich beliebig 
kaskadieren läßt; lediglich der Anfang eines Busses 
besitzt einen Kurzschlußstecker. 


Dadurch, daß das Zuteilungssignal immer dort wei- 
terläuft, wo es angehalten wurde, ist gewährleistet, 
daß alle Moduln fair behandelt werden, d. h. alle ha- 
ben dieselbe Wahrscheinlichkeit, einen Bus zu be- 
kommen. Zudem ist ausgeschlossen, daß ein Prozes- 
sor mit einer hohen Anforderungsrate alle anderen 
blockiert. 

Von mehreren freien Bussen bekommt jeder Modul 
immer denjenigen zugewiesen, der am schnellsten 
verfügbar ist. Da die einzelnen Busse unabhängig 
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voneinander und gleichzeitig vergeben werden, las- 
sen sich beliebig viele Busse zur Erhöhung des Daten- 
flusses einsetzen; damit kann das Multi-Common- 
Bussystem an die Zahl der eingesetzten Moduln ange- 
paßt werden. 


In einem Multi-Tasking-System läßt sich ein Bussy- 
stem effizienter nutzen, wenn die Busanforderungen 
nach den Prioritäten der anfordernden Tasks bearbei- 
tet werden. 


Die oben beschriebene Bus-Arbitrierung läßt sich 
sehr leicht mit Prioritäten versehen: 


Zusätzlich zu den einzelnen Datenbussen werden alle 
Modulbusse durch einen Prioritätenbus verbunden, 
auf dem für jede Anforderungspriorität eine Leitung 
reserviert ist. Fordert ein Modul einen Datenbus an, so 
legt es zunächst nur ein Signal auf diejenige Leitung 
des Prioritätsbusses, die seiner Anforderungspriorität 
entspricht. Gleiche Signale verschiedener Moduln 
werden mit der ODER-Funktion verknüpft. 


Jeder Modul kann nun für sich entscheiden, ob seine 
Anforderung der augenblicklich höchsten Priorität 
entspricht. Nurin diesem Fall wird das oben erwähnte 
Anforderungssignal auf den Modulbus und zu den 
einzelnen Knotenpunkten weitergegeben. Die zirku- 
lierenden Zuteilungsflanken werden dann zunächst 
alle Anforderungen der augenblicklich höchsten Prio- 
rität bedienen, worauf diese ihre Priorität vom Priori- 
tätenbus entfernen. Darauf können auch für weniger 
wichtige Tasks Anforderungssignale erzeugt werden. 


5 Implementierung 


Ein Multi-Common-Bus mit der beschriebenen 
Bus-Arbitierung befindet sich zur Zeit in Heidelberg 
in der Erprobungsphase. Dieses Bussystem soll mit 

15 Einzelbussen innerhalb eines Multi-Mikropro- 
zessorsystems verwendet werden, anwendungsab- 
hängig sind bis zu 300 Prozessoren vorgesehen. 
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Peter L. Andersen 


Verteiltes System mit 


Einplatinen-Computern 


Problemlösungen hoher Komplexität werden in zuneh- 
mendem Maße in der Form verteilter Systeme reali- 
siert. Vorteile, die sich dabei ergeben, sind z. B. ver- 
einfachter Aufbau und dadurch geringere Kosten 
sowie ein transparentes, leicht erweiterbares Konzept. 
Allerdings ist es wichtig, ein brauchbares Kommuni- 


Verteilte Systeme lassen sich grundsätzlich in zwei 
Gruppen aufteilen, nämlich Konfigurationen, bei denen 
die Funktionsgruppen so angeordnet sind, daß diese 
über einen gemeinsamen parallelen Datenbus kommuni- 
zieren können, und andere, bei denen die Funktions- 
gruppen örtlich so weit voneinander getrennt sind, daß 
sie über eine serielle Schnittstelle miteinander verbun- 
den werden müssen. 


1 Anwendungsbeispiel 


Das Computersystem in diesem Beispiel dient zur 
Überwachung und Sicherung eines Komplexes, der aus 
mehreren Gebäuden besteht (Bild 1). Das System über- 
wacht die drei bereits existierenden Gebäude, das 
geplante vierte soll nach Fertigstellung ebenfalls ange- 
schlossen werden, in jedem Gebäude ist eine Kontroll- 
station vorgesehen, außerdem eine Zentrale, mit dem 
sich der Gesamtkomplex übersehen läßt. Für Anwen- 
dungen dieser Art ist ein Verteilen der Systemfunktion 
über den Gebäudekomplex mit zwei Vorteilen verbun- 
den: Die Installationskosten verringern sich und die 
Zuverlässigkeit des Systems wird erhöht. 


2 Hardware-Implementierung 


2.1 Sternförmiges Netzwerk 





In einem sternförmigen Netzwerk kann eigentlich 
jedes Übertragungsverfahren verwendet werden. Weil 
immer nur eine Einheit mit einer anderen kommuni- 
ziert, spielt die Kommunikationsform eine untergeord- 
nete Rolle. In diesem Beispiel wird die RS232C-Daten- 
übertragung angewendet. 

Herz der Stern-Konfiguration ist eine Master-Einheit. 
In ihr müssen die Mittel vorgesehen werden, die die 


kationsschema zu verwenden, das für die Verbindung 
der einzelnen Systembestandteile sorgt. Hier wird an 
einem Beispiel gezeigt, wie ein verteiltes System mit 
Einplatinen-Computern aufgebaut ist, bei dem stan- 
dardmäßige Hard- und Softwarebestandteile verwen- 
det werden. 


Kommunikation mit den Untereinheiten (Slaves) aus- 
führen. Eine kostengünstige Lösung ergibt sich, wenn 
die Kommunikationstreiber auf einer gemeinsamen Pla- 
tine untergebracht sind. In dem hier beschriebenen 
Anwendungsbeispiel sind vier Slaves notwendig, die 
vom Master gesteuert werden. Diese Funktion wird von 
der intelligenten Steuereinheit iSBC 544 ausgeführt. 
Diese Platine arbeitet mit einer Baudrate, die software- 
mäßig einstellbar ist. Die Intelligenzfunktionen entla- 
sten den Hostrechner von den Kommunikationsaktivitä- 
ten. Wenn außer den vier Untereinheiten weitere Slaves 
benötigt werden, kann das System durch einfaches Hin- 
zuführen einer solchen Kommunikationseinheit erwei- 
tert werden. 
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Bild 1. Gebäudekomplex, für den die Überwachungs- und 
Alarmeinrichtung konzipiert ist 
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Als Slave-Prozessoren bieten sich die Einplatinen- 
Computer iSBC 80/108 an, die preiswert sind und aus- 
reichende Verarbeitungskapazität bieten. Die Platinen 
besitzen sowohl ein RS232C- als auch ein 20-mA-Strom- 
schleifen-Interface und lassen sich sowohl in der RS232- 
als auch in EIA-Betriebsart verwenden. Der EIA-Betrieb 
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unterscheidet sich vom RS232C-Standard nur dadurch, 
daß eine größere Übertragungsdistanz, allerdings bei 
geringerer Baudrate, möglich ist. In dem Anwendungs- 
beispiel sind beide Betriebsarten möglich. 

Die auf der Kommunikationsplatine vorzusehenden 
Verbindungen zur Einstellung der Betriebsart werden 
am Stecker J1 vorgenommen (Bild 2). Zu beachten ist, 
daß die Signale „Ready to Send“ und „Clear to Send“ 
miteinander verbunden werden müssen, um das kor- 
rekte Arbeiten der USART ohne die Steuerung durch ein 
Modem zu gewährleisten. Die Sende- und Empfangssi- 
gnale werden außerdem miteinander vertauscht. 

Wenn ein RS232C-Signal über eine längere Distanz 
übertragen wird, muß das aus Gründen der Zuverlässig- 
keit mit niedriger Geschwindigkeit geschehen. Im hier 
beschriebenen Beispiel ist eine Baudrate von 1200 aus- 
reichend, denn das Auslagern von Intelligenz in die 
Untereinheiten minimiert die Datenmengen, die über- 
tragen werden müssen. 

Während der Entwicklungsphase der Hardware muß 
auch das Kommunikationsschema für die Übertragung 
zwischen Master und Slave festgelegt werden. Dieses 
Problem kann sehr einfach gelöst werden, denn die 
Kommunikationsplatine iSBC 544 verfügt über Master/ 
Slave-Protokoll-Funktionen. Diese werden von drei 
Hardwaremerkmalen unterstützt. Das erste ist der zwei- 
seitige Speicher Dual-Port-Memory auf der Platine. Hier 
können Daten und Befehle für die Kommunikation zwi- 
schen Slave und Host-Prozessor gespeichert werden. Die 
zweite Einrichtung erzeugt immer dann, wenn der Host- 
computer in den ersten Platz des Dual-Port-RAMs ein- 
schreibt, einen Flag-Interrupt. Der Interrupt wird 
zurückgesetzt, wenn der Speicherinhalt vom Slave-Pro- 
zessor gelesen wurde. Drittens erzeugt die Ausführung 
der SOD-Instruktion des 8085 A-2 einen Multibus-Inter- 
rupt, der den Hostcomputer davon unterrichtet, daß der 
Slave bedient werden muß. Mit diesem Interrupt kann 
eine Service-Routine zur Bedienung des Slave-Boards 
aktiviert werden. Eine ausführliche Beschreibung der 
Merkmale des iSBC 544 findet man in [1]. 


2.2 Ringstruktur 2 


Im Gegensatz zur Sternkonfiguration unterliegt die 
Hardware der ringförmigen Kommunikationsleitung 
gewissen Beschränkungen. Es muß ein Übertragungs- 
schema verwendet werden, das es jeder Untereinheit- 
erlaubt, nacheinander die Kontrolle über das Kommuni- 
kationsnetz zu erlangen, um eine Nachricht‘ zu. über- 
tragen. ER 

In einem Ringnetz ist sowohl Halb- als auch Voll- 
Duplex-Betrieb möglich. Während der Hardwareauf- 
wand bei einer Halb-Duplex-Übertragung geringer ist, 
muß das Kommunikationsprotokoll in diesem Fall 
etwas enger ausgelegt werden, weil die Übertragung 
immer nur in eine Richtung möglich ist. Aus prakti- 
schen Gründen ist keine Priorität für Master oder Slaves 
vorgesehen. Alle Teilnehmer empfangen die Signale, 


egal wer sie absendet. Die Software muß so konzipiert 
sein, daß) immer nur eine Untereinheit kommunizieren 
kann. Ein Beispiel für ein Halb-Duplex-Netzwerk ist das 
Ethernet. 

Software,für Voll-Duplex-Betrieb ist unkomplizierter. 
‘In diesem Fall wird vorausgesetzt, daß im System nur 
ein, Master vorgesehen ist, der die Ausgangsleitungen 
treibt. Eine beliebige Zahl von Slaves treibt die Ein- 
gangsleitungen. Die Kommunikation wird auf Anforde- 
rung des Masters ausgeführt. 

Für den Betrieb im Netzwerk müssen einige auf der 
Platine befindliche Optionen aktiviert werden. Die erste 
Optien ist die Konfigurierung der Ausgangstreiber als 
Tri-State-Treiber. Dadurch ist es möglich, daß nur die 
Platine, die die Steuerung der Kommunikationssignale 
übernimmt, Daten auf den Ausgangsleitungen absetzen 
kann. Die Konfiguration von Master und Slave unter- 
scheiden sich (Bild 3). Die Ausgangssignal-Leitungen 
werden durch das DTR-Signal (Data Terminal Ready) 
der USART gesteuert. 

Bild 4 zeigt den Verdrahtungsaufwand, der für ein 
Voll-Duplex-Ring-Netzwerk mit einem Master und vier 
Slaves erforderlich ist. Für den Abschluß der Kommuni- 
kationsleitungen werden Widerstände vorgesehen. Eine 
genaue Bestimmung der Widerstandswerte ist in [2] 
beschrieben. Für den RS422-Sektor des Boards sind 
Widerstände zur Erzeugung der Vorspannung vorzuse- 
hen, die sich überschlagsmäßig folgendermaßen bestim- 
men lassen: 

Rpı = 4500/(18,6 -1,6x N) 

Rp = 2500/(18,6 - 1,6 x N) 

(N ist die Anzahl der Slaves). 

In dem hier beschriebenen Beispiel beträgt der Wert von 
Rgı 370 &, Rp, hat 205 9. 

Auf einer verdrillten Leitung kann mit einer Baudrate 
von 19,2 kBd nach dem RS422-Standard eine Entfer- 
nung von etwa 1,2 km überbrückt werden. Das ist für die 
hier beschriebene Anwendung ausreichend, da die 
größte Entfernung bei etwas mehr als 500 m liegt. 





3 Software-Implementierung 


Nach der Phase der Hardwaredefinition müssen 
zunächst die Protokolle definiert werden, nach denen 
die Datenübertragung und die gegenseitige Steuerung 
(„Handshaking‘“) ausgeführt wird. Das Handshaking ist 
die Hintergrundkommunikation, mit der die Synchroni- 
sierung und Integrität der Kommunikationseinrichtung 
gewährleistet wird. 


3.1 Beziehung zwischen Master und Slave 


Um einen geordneten Fluß von Daten zwischen den 
Stationen, die am Netz angeschlossen sind, zu gewähr- 
leisten, muß die Software Prioritäten zuweisen, damit 
zu einem Zeitpunkt immer nur ein Teilnehmer sendet. 
Die einfachste Möglichkeit dazu ist eine Master-Slave- 
Hierarchie. Dabei wird ein Teilnehmer als Master defi- 
niert und die anderen als Slaves. Jedem Slave wird eine 
Zeit zugewiesen, in der er anderen Teilnehmern Daten 
übermitteln kann. Der Master steuert die Priorisierung 
der Slaves. Die Komplexität des Systems kann reduziert 
werden, wenn ein Voll-Duplex-Übertragungsverfahren 
gewählt wird. In dieser Betriebsart empfangen alle 
Slaves die Signale des Masters und übertragen ihre 
Nachrichten über einen gemeinsamen seriellen Kanal 
zum Master. Ein Nachteil dieser Technik ist die Tatsa- 
che, daß Übertragungen zwischen den Slaves direkt 
nicht möglich sind. 

Bild 5 zeigt, wie ein Master die Zeitfenster festlegt, 
während deren ein Slave die Kontrolle über den Ausga- 
bekanal zur Übertragung von Nachrichten zum Master 
übernehmen kann. Jedem Slave ist eine Adresse zur 
Identifizierung zugeordnet. Jedes Datenpaket enthält 
eine Adresse. Wenn ein Slave seine Adresse im Paket, 
das vom Master ausgesendet wurde, erkennt, steht ihm 
ein festes Zeitfenster zur Verfügung, in dem eine Nach- 
richt zum Master zurückgesendet werden kann. 
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Abkurzungen 
RD=Receive Data 
DM=Data Mode 
SD= Send Data 


TR=Terminal Ready 
RS=Request to Send 


Bild 4. Leitungsverbindungen zwischen dem Master und den 
Slaves 
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Bild 5. Erzeugung der Zeitfenster 
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3.2 Datenpaket-Formate 


Die Kommunikation zwischen jedem Slave und dem 
Master besteht aus der Übertragung von Datenpaketen. 
Jedes Paket enthält die Handshaking-Information (z.B. 
Checksumme und Anzahl der Nachrichten) sowie die 
Informationen, die zwischen den Stationen des Netzes 
ausgetauscht werden sollen. Die Handshaking- 
Abschnitte des Übertragungssignals werden auch dazu 
benutzt, die Integrität der Übertragung in bezug auf 
externe Einflüsse, z. B. Störungen, zu überwachen. 

Debugging und Systemwartung werden minimiert, 
wenn eine Einrichtung vorgesehen wird, mit der die 
Kommunikationssignale leicht überwacht und interpre- 
tiert werden können. In dem hier beschriebenen Bei- 
spiel wird ein ASCII-kompatibles Kommunikationsfor- 
mat verwendet. Dadurch ist es möglich, mit einem CRT- 
Terminal, das an die Signalleitung angeschlossen wird, 
die Kommunikation zu überwachen. 

Jedes Nachrichtenpaket beginnt und endet mit einem 
bestimmten Zeichen. Dieses Zeichen kann nicht inner- 
halb der Nachricht verwendet werden. Zu Beginn eines 
Nachrichtenpaketes wird „Line Feed“ und zum Ende 
„Carriage Return“ gesendet. Durch diese Zuweisung 
kann ein Nachrichtenpaket leicht interpretiert werden. 

Die Zusammensetzung eines Datenpaketes ist in 
Bild 6 dargestellt. Ein großer Teil der Nachricht ist zur 
Sicherstellung der Systemintegrität vorgesehen. Die 
Notwendigkeit einer Adresse wurde bereits erwähnt. 
Zwei Zeichen genügen, um 256 unterschiedliche Adres- 
sen (00...FFH) zu erzeugen. Dem Master wird die 
Adresse 0 zugewiesen, die restlichen 255 Adressen ste- 
hen für Slaves zur Verfügung. 

Das nächste Feld beschreibt die Art der Nachricht, die 
gesendet wird, und die Aktion, die vom Empfänger 
ausgeführt werden muß. Eine Analyse von Erfordernis- 
sen der Systemkommunikation zeigt, daß fünf Nachrich- 
tentypen ausreichend sind. Mit einem einzigen Byte in 
diesem Feld können insgesamt 16 Typen unterschieden 
werden. Damit bleiben elf für spätere Erweiterungen 
frei. In diesem Beispiel werden folgende Typen ver- 
wendet: 

— Typ 0: Dies ist eine Aufforderung des Masters an den 

Slave für einen Reset. Der adressierte Slave generiert 


Ziel- Kom- | Nachrichten- 
station |mando | Zähler 
(0...255)| (0...F) | (0..FF) 





Start- 


zeichen 
(Line Feed) 








Erweiterung | Tgsk- 


j Response Exchange- 
EIER er 

EBENEN  - 
[7 


Bild 6. Format des Kommunikationspaketes 
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einen Software-Reset. Dieses Kommando wird nur 

benutzt, wenn die Kommunikation durch andere Mit- 

tel nicht aufgebaut werden kann. 

— Typ 1: Dieses Kommando wird zur Synchronisierung 
von Master und Slave benutzt. Der Message-Zähler 
wird auf 0 zurückgesetzt. Dieses Kommando kann nur 
vom Master ausgegeben werden. 

- Typ 2: Die Nachricht vom Typ 2 ist als diejenige 
definiert, die die Information enthält, die zwischen 
den einzelnen Stationen des Kommunikationsnetzes 
weitergeleitet wird. Das exakte Format dieser Daten ist 
woanders festgelegt. Dies ist die einzige Nachricht, die 
nicht die Handshaking-Natur aufweist. 

— Typ 3: Diese Message zeigt an, daß der Teilnehmer 
erreicht wurde und bereit ist, zu reagieren. Wenn eine 
normale Kommunikation aufgebaut wurde und keine 
Nachricht ausgesendet wird, wird diese Message zwi- 
schen Master und Slave dauernd gesendet. 

— Typ 5: Diese Nachricht wird vom Slave benutzt, um 
auf die Aufforderung des Masters zur Synchronisie- 
rung zu antworten. Die Quittierung dieses Signals 
zeigt an, daß der Slave alle notwendigen Operationen 
ausgeführt hat und die Message-Zähler bereit sind, 
neue Nachrichten zu empfangen. 

Das nächste Feld wird dazu benutzt, die Anzahl der 
Messages anzugeben, die Daten enthalten und von 
jedem Teilnehmer empfangen oder gesendet werden 
müssen. Das erste Zeichen dient zur Anzeige der Zahl 
der Messages, die vom Master ausgesendet und vom 
Slave empfangen wurden. Das zweite Zeichen zeigt die 
Zahl der Messages, die der Master ausgesendet hat. Das 
interne Softwareprotokoll benutzt diese Felder, um fest- 
zustellen, ob eine Daten-Message vom adressierten 
Slave korrekt empfangen wurde. Wenn die Antwort- 
Message nicht die richtigen Zahlen enthält, kann die 
Message erneut gesendet werden. 

Das Datenfeld enthält die Informationen, die an den 
empfangenden Teilnehmer gesendet werden. Der 
genaue Inhalt wird in Zusammenhang mit Erweiterun- 
gen des Betriebssystems erläutert. 

Zur Gewährleistung der Integrität der übertragenen 
Nachricht wird die Prüfsumme hinzugefügt. Dieses Feld 
enthält eine 8-Bit-Summe (256) aller übertragenen 
ASCII-Zeichen, beginnend mit „Line Feed“ bis zum 
letzten Zeichen des Datenfeldes. Es wird zum Vergleich 
der berechneten Prüfsumme der empfangenen Zeichen 
mit dem vom sendenden Teilnehmer ausgegebenen Zei- 
chen verwendet. Wenn die zwei Zahlen übereinstim- 
men, wird die Nachricht als gültig erkannt. Das letzte 
Feld ist ein Zeichen, das das Ende der Nachricht kepn- 
zeichnet. Dazu wird „Carriage Return“ benutzt.. 


! 


3.3 Konzepte für Multitasking-Nachrichten 


Die Entwicklung von Systemen mit verteilten Proze$- 
soren setzt auch eine Multitasking-Umgebung voraus. 
Die Möglichkeit, ein Anwendungsproblem in einzelnen 
Tasks aufzuteilen, führt zu erheblichen Vereinfachun- 


gen des Entwicklungs- und Implementierungsprozesses. 
In der Praxis repräsentieren allerdings nur wenige Tasks 
völlig isolierte Funktionen. Ein gewisser Grad von Kom- 
munikation zwischen den Tasks ist erforderlich. Das 
reicht von’einfacher Synchronisation bis zum Daten- 
transfer. Dieser Prozeß wird durch ein Echtzeit-Betriebs- 
system vereinfacht. Der Kern des Betriebssystems 
iRMX 80 -ist ein gutes Beispiel dafür. Es verfügt über 
einen kleinen-Überbau, benötigt geringe Speicherkapa- 
zität und arbeitet in Zusammenhang mit fast allen 8-Bit- 
Platinencomputern von Intel. 

Eine Message des iRMX 80 kann man mit einem Brief 
vergteichen, der jemandem zugeschickt wird. Dieser 
wird in einem Postamt abgegeben (Exchange) und wird 
dann dem Empfänger übergeben. Jeder Bereich der 
iRMX-Implementierung kann auf diese Weise benützt 
werden. Wenn eine serielle Kommunikationsverbin- 
dung zwischen den Prozessoren benutzt wird, ent- 
spricht das dem Versenden eines Telegramms. 

Es gibt unterschiedliche Teile einer Message. Jeder 
Teil hat eine bestimmte Funktion und Format innerhalb 
der Nachrichtenstruktur. Bevor eine Nachricht erzeugt 
wird, muß ein Medium in Form eines RAM-Blocks 
bereitgestellt werden, das diese Nachricht enthält. Um 
immer Speicherplatz zur Verfügung stellen zu können, 
besitzt das Betriebssystem eine Einrichtung zur Spei- 
cherverwaltung. Deren Aufgabe ist die Wiederverwen- 
dung von Blocks, die inzwischen nicht mehr benötigt 
werden, zur Erzeugung weiterer Messages. Dieser Vor- 
gang wird jedesmal ausgeführt, wenn die sendende Task 
die Erzeugung einer Nachricht beginnt. Wenn das Kom- 
munikationsprogramm erfolgreich eine Nachricht zum 
empfangenden Teilnehmer übermittelt hat, wird der 
Speicherblock an den Pool der freien Speicher zurück- 
gegeben. Wenn der Empfänger eine Nachricht erhält, 
muß dieser wiederum einen Block von der Speicherver- 
waltung erhalten, um die Information zu speichern, bis 
sie von der Ziel-Task verarbeitet werden kann. Diese 
Task gibt den Block an den Pool zurück, wenn die 
Aktivitäten ausgeführt worden sind. 

Wie bei jeder anderen Art von Nachricht muß natür- 
lich auch ein Empfänger existieren. Weil der Kern des 
iRMX 80 für die Verwendung in Zusammenhang mit 
mehreren Tasks auf dem gleichen Prozessor konzipiert 
ist, ist der Zieladreßmechanismus nicht im eigentlichen 
Message-Header enthalten. Aus diesem Grund muß das 
Ziel innerhalb des Aufrufes der iRMX-Prozedur in der 
Parameterliste spezifiziert werden. Wenn die Ziel- 
adresse nicht bekannt ist — ein Fall, der beim Entwurf 
von Multiprozessorsystemen regelmäßig auftritt —, ist es 
notwendig, eine Erweiterung des Betriebssystemes vor- 
zusehen, mit der es möglich ist, jeder Message einen 
Zielnamen zuzuweisen. Die Erzeugung eines „Target- 
Exchange-Namens“ ist allerdings nicht sehr kompliziert. 


3.4 Erweiterung des Betriebssystemes 


Der Kern des Betriebssystems iRMX 80 benutzt einen 
kleinen RAM-Block, um Daten zu speichern, die Eigen- 


schaften und Zustand jeder Exchange betreffen. Dieser 
Bereich umfaßt in der Regel 10 Byte. 

Wenn der Kern des Betriebssystemes nicht neu 
geschrieben werden soll, kann das Format des 
Exchange-Descriptors nicht geändert werden und das 
Identifikationsfeld muß in Form zusätzlicher Bytes die- 
sem Speicherblock hinzugefügt werden. Zwei Merkmale 
des iRMX 80 machen eine direkte Implementation die- 
ses Konzeptes allerdings unmöglich. Erstens existiert 
ein besonderer Exchange-Descriptor bereits. Dieser ist 
der Interrupt-Exchange, der fünf Byte als eine Interrupt- 
Nachricht hinzufügt. Zweitens müssen, wenn eine 
zusätzliche Erweiterung vorgesehen ist, alle Exchanges 
als Interrupt-Exchanges erzeugt werden, damit gemein- 
same Programme verwendet werden können. Während 
das alleine noch kein Hinderungsgrund ist, kommt 
hinzu, daß der interaktive Konfigurator (ICU 80) die 
Hinzufügung von Feldern weder zum Standard- noch 
zum Interrupt-Exchange-Descriptor zuläßt. Deshalb ist 
eine andere Methode zur Erweiterung zulässig. 

Die Operation RQCXCH erzeugt eine Exchange bei 
einer Adresse, die durch einen Parameter der Aufrufin- 
struktion spezifiziert ist. Wenn die Benutzer-Software 
diese Exchanges aufbaut, kann der Name jeder 
gewünschten Exchange vorangestellt werden. 

Beim Standard-Kern des iRMX 80 sind sechs Zeichen 
als Name für jede Task erlaubt. Eine logische Erweite- 
rung dieses Konzeptes führt zu einem Namen aus sechs 
Zeichen für jede dieser Exchanges. Der Descriptor wird 
daher durch Hinzufügen von sechs Byte zu seinem For- 
mat erweitert. In der Praxis ist das allerdings noch nicht 
ausreichend, weil diese Exchanges dynamisch erzeugt 
werden müssen. Der Speicherbereich, der die Exchanges 
repräsentiert, muß nicht unbedingt aus einem kontinu- 
ierlichen Adreßbereich bestehen. Aus diesem Grund 
muß ein zusätzliches Speicherwort, das einen Pointer 
enthält, der auf das nächste Exchange-Feld zeigt, hinzu- 
gefügt werden. Der Wert Null in diesem Feld zeigt an, 
daß keine zusätzlichen Exchanges vorhanden sind. 
Bild 7 zeigt die Struktur dieser Felder. 

Die Erzeugung von Software zur Unterstützung der 
Erweiterungen ist relativ unkompliziert. Zwei Funktio- 
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Bild 7. Struktur von Named-Exchange-Feldern 
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nen sind erforderlich: Eine, die die „Named Exchanges“ 
erzeugt und eine zweite, die die Adresse einer 
Exchange, die den vorgegebenen Namen entspricht, 
zurückgibt. Ein komplettes Listing der erforderlichen 
Software ist in [3] enthalten. Die Zuweisung der Spei- 
chersegmente für die Exchange-Descriptoren wird durch 
die Speicherverwaltung ausgeführt. 


3.5 Aufbau der seriellen Kommunikation 


Die Erstellung von Software für eine serielle Kommu- 
nikation führt zu echten Multitasking- und Multiprozes- 
sor-Fähigkeiten. Die Notwendigkeit von zwei Kommuni- 
kationspaketen für Slave- und Masterprozessor zeigt, 
daß zwei verschiedene Tasks erforderlich sind. Eine 
genaue Untersuchung der Kommunikationserforder- 
nisse ergibt, daß das System in drei Ebenen aufgebaut 
werden kann (Bild 8). Die erste ist als Protokoll definiert 
und enthält den Code, der zur Implementierung des 
Algorithmus für Slave- und Master-Stationen erforder- 
lich ist. Die zweite Ebene, die Verbindungsebene, ent- 
hält den Code, der für allgemeine Operationen, z.B. 
Message-Erzeugung und Daten-Warteschlangen-Verwal- 
tung, benötigt wird. Die dritte Ebene besteht aus einem 
speziellen Interface an die physikalische Hardware für 
den Aufbau der Kommunikationsverbindung. Diese 
muß an die jeweilige Konfiguration angepaßt sein. 


3.6 Kommunikationspaket für Protokoll- und 
Verbindungsebene 





Für dieses Anwendungsbeispiel sind zwei Kommuni- 
kationspakete auf der Protokollebene erforderlich. Die 
Implementierungen für Master- und Slave-Protokoll 
sind vollständig in [3] abgedruckt. Das Kommunika- 
tionspaket für die Verbindungsebene sieht eine Menge 














Bild 8. Die Ebenen der Übertragungseinrichtung 
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von Prozeduren vor, mit denen sowohl die Protokoll- als 
auch physikalische Ebenen unterstützt werden können. 
Vollständige Listings dieser Programme sind in [3] zu 
finden. 


3. 


7 Kommunikationspaket der physikalischen Ebene 


Dieses Paket dient der Anpassung an die Konfiguratio- 


nen des Host-Prozessors und der USART. Vier Prozedu- 
ren müssen von dieser Ebene ausgeführt werden: 


CQSINIT Diese Prozedur enthält alle Operationen, die 
notwendig sind, um die Zeitgeber, Zähler und 
USARTSs, die mit dem Kommunikationscode in Ver- 
bindung stehen, zu initialisieren. Außerdem definiert 
diese Prozedur die Interrupt-Serviceroutinen für die 
USARTSs und gibt die entsprechenden Interruptebenen 
frei. 

CQ$1STARTSMSG Diese Prozedur versetzt die USART 
in einen Zustand, bei dem der Sender freigegeben ist. 
Die Ausführung der Prozedur sollte in einem Interrupt 
resultieren, der von der „Transmitter-Ready“-Leitung 
der USART generiert wird. 

CQMIVT Diese Interrupt-Serviceroutine hängt mit der 
„Receiver-Ready“-Leitung der USART zusammen. In 
diese Routine wird jedesmal eingesprungen, wenn ein 
Zeichen empfangen wurde. Für die Slave-Stationen 
trägt diese Prozedur die Bezeichnung CQSIVT. Der 
Name ist allerdings unwichtig, weil die Lage dieser 
Routine, bei der Initialisierung durch das CQS$INIT- 
Programm an den Kern des iMRX 80 weitergeleitet 
wird. Wenn das Zeichen für das Ende der Message 
(Carraiage Return) auftritt, wird eine Message an die 
Task der Protokollebene weitergegeben, indem mit 
Hilfe der iMRX-Grundoperationen RQISND eine 
Nachricht an die Interrupt-Exchange RQL6EX weiter- 
gereicht wird. 

SEND$CHAR Wie die CQMIT-Routine ist dies eine 
Interrupt-Handler-Prozedur. In diese Routine wird 
gesprungen, wenn die USART signalisiert, daß sie zur 
Übertragung eines Zeichens bereit ist. Dann wird ein 
neues Zeichen aus der Datenwarteschleife entnommen 
und der empfangenden Station übertragen. Wenn es 
sich bei diesem Zeichen um das Ende der Nachricht 
handelt, werden Flags gesetzt und die USART ge- 
sperrt. 

Das Listing für den Treiber ist in [3] abgedruckt. In 


diesem Beispiel wird das serielle Multimodul-Board. 
iSBX 351 an einen Einplatinencomputer iSBC, 80/24.an- 
geschlossen. a 
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Elektronik-Magazin 


2089 Ergänzungspackung — IC-Fassungen DM 9,90 
DM 2095 Cassetten-Interface DM 129,50 
5964 Schwachstrom-Spezial-Relais DM 14,90 
2090 Mikro-Comp:'ter microtronic DM 389,— 


Gerne übersenden wir Ihnen auf Anfrage einen 
ausführlichen Prospekt. | 
Franzis-Verlag, Karlstraße 37, 8000 München 2 ) 


Ein echter Mikrocomputer — 
für unendlich viele Möglichkeiten. 389.— 








macht Mikrocomputer anwendbar 


Das finden Sie in mc: 


© Einsatzmöglichkeiten der gängigen Hard- und Software. 

© Laborerprobte Applikationen: Mikrocomputer dienen in vielen Bereichen 
zur Steuerung von Geräten und zur automatischen Erfassung und Aus- 
wertung von Meßergebnissen. MC sagt Ihnen wie, und hilft auch bei der 
Beseitigung von Interface-Problemen. 

® Geprüfte Programme, für alle gängigen Rechner- und Prozessortypen. 
© Für die Adaption vorhandener Programme auf andere Systeme gibt MC 
durch umfassende Dokumentation der rechnerinternen Betriebssoftware — 
die oft nicht einmal der Computer-Hersteller bietet — gezielte 
Anleitungen 

© Programmierhilfen: Als Software-Entwickler hilft Ihnen MC, Zeit und 
Geld zu sparen mit Standard-Routinen, Hilfsprogrammen, Softwarekniffen 
und Hinweisen zu Betriebssystem-Erweiterungen. 


© Hardware-Tips: MC hilft Ihnen bei der Entwicklung und beim Bau 
individueller Hardware-Bausteine: Einplatinen-Mikrocomputer, Speicher- 
Erweiterungen, Interface-Schaltungen - kurz alles, was man eben doch 
selber machen muß. 


© Software-Informationen: MC berichtet über neue Programmpakete, 
gibt Übersichten über Programmiersprachen und Betriebssysteme. 

In Grundlagenbeiträgen werden die logischen Zusammenhänge des 
Programmierens geschildert. 


© Grundlagenbeiträge über Arbeitsweise und Eigenschaften von Mikro- 
computern und Peripherie. 


© Wie denken Computer? MC zeigt Ihnen, wie Ihr Tischcomputer intern 
denkt”. Das ermöglicht Ihnen, Ihr Gerät noch besser auszunutzen. 


Ein Abonnement können Sie hier oder bei jeder 


Buchhandlung bestellen! . 


Bestellkarte 


für ein Abonnement, Sonderheft oder Probeheft 
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© Natürlich lesen Sie in MC auch wissenswerte Detail-Informationen 

aus der Mikrocomputer-Technik und ihren Randgebieten: Marktübersichten, 
Seminar-Termine, aktuelle Entwicklungen, Berichte über neue Hardware- und 
Softwareprodukte, Tests und Vergleiche von Computern und Programmier- 
sprachen. 


@ Eine „Programm-Börse“, in der Sie als Leser für eine minimale Schutz- 
gebühr die Möglichkeit haben, Programme privat anzubieten. 


MC erscheint monatlich. Das Einzelheft kostet 6,- DM im Inland, 
6,50 DM im Ausland, 
das Jahresabonnement 60,— DM im Inland, 
66,- DM im Ausland. 
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Bestellkarte 


für ein Abonnement, Sonderheft oder Probeheft 





Bitte senden Sie ab 


U] Elektronik 


26 Hefte pro Jahr, Jahresabonnementspreis 
115.20 DM im Inland, im Ausland 138.- DM 


[ Funkschau 


26 Hefte pro Jahr, Jahresabonnementspreis 
96.- DM im Inland, im Ausland 118.80 DM. 


Name/Vorname 





Beruf 


Straße 


regelmäßig die Zeitschrift 


2ER 


12 Hefte pro Jahr, Jahresabonnementspreis 
39.60 DM im Inland, im Ausland 48.— DM. 


Dr 


12 Hefte pro Jahr, Jahresabonnementspreis 
60.- DM im Inland, im Ausland 66.- DM 





PLZ/Ort 





Datum Unterschrift 


Bitte senden Sie ab 


U] Elektronik 


26 Hefte pro Jahr, Jahresabonnementspreis 
115.20 DM im Inland, im Ausland 138.- DM 


D[ Funkschau 


26 Hefte pro Jahr, Jahresabonnementspreis 
96.- DM im Inland, im Ausland 118.80 DM. 


Name/Vorname 


Beruf 


regelmäßig die Zeitschrift 


DD 


12 Hefte pro Jahr, Jahresabonnementspreis 
39.60 DM im Inland, im Ausland 48.- DM 


mi y 5 — 


12 Hefte pro Jahr, Jahresabonnementspreis 
60.- DM im Inland, im Ausland 66.- DM. 





Straße 


PLZ/Ort 








Datum Unterschrift 


In den genannten Abonnementspreisen sind sämtliche Nebenkosten, einschließlich Porto, 
enthalten. Bei verlagsseitiger Änderung muß die Berechnung aus gesetzlichen Gründen 
(Preisbindung!) zum neuen Preis erfolgen. 


Die Kündigung ist jeweils 8 Wochen zum Kalenderjahresende möglich. 

Die Abonnementsgebühr ist nach Erhalt der Rechnung fällig. Preise Stand 10/82. Falls Sie 
Abbuchung vom Konto wünschen, beachten Sie bitte die Rückseite. Diese Vereinbarung 
können Sie innerhalb einer Woche schriftlich widerrufen. 





Multi-Mikrocomn 





‘ar-Systeme |_ 


In den genannten Abonnementspreisen sind sämtliche Nebenkosten, einschließlich Porto, 
enthalten. Bei verlagsseitiger Änderung muß die Berechnung aus gesetzlichen Gründen 
(Preisbindung!) zum neuen Preis erfolgen. 


Die Kündigung ist jeweils 8 Wochen zum Kalenderjahresende möglich. 

Die Abonnementsgebühr ist nach Erhalt der Rechnung fällig. Preise Stand 10/82. Falls Sie 
Abbuchung vom Konto wünschen, beachten Sie bitte die Rückseite. Diese Vereinbarung 
können Sie innerhalb einer Woche schriftlich widerrufen. 
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© Natürlich lesen Sie in MC auch wissenswerte Detail-Informationen 

aus der Mikrocomputer-Technik und ihren Randgebieten: Marktübersichten, 
Seminar-Termine, aktuelle Entwicklungen, Berichte über neue Hardware- und 
Softwareprodukte, Tests und Vergleiche von Computern und Programmier- 
sprachen. 

© Eine „Programm-Börse“, in der Sie als Leser für eine minimale Schutz- 
gebühr die Möglichkeit haben, Programme privat anzubieten. 


- hei ich. Ei kostet 6,- DM im Inland, 
macht Mikrocomputer anwendbar 51 in ausana > Einzelheft kostet 6,-. DM im Inland 
das Jahresabonnement 60,- DM im Inland, 


66,- DM im Ausland. 










Das finden Sie in MC: 


© Einsatzinöglichkeiten der gängigen Hard- und Software. 
“© Laborerprobte Applikationen: Mikrocomputer dienen in vielen Bereichen 
zur Steuerung von Geräten und zur automatischen Erfassung und Aus- 
wertung von Meßergebnissen. MC sagt Ihnen wie, und hilft auch bei der 
Beseitigung von Interface-Problemen. 
© Geprüfte Programme, für alle gängigen Rechner- und Prozessortypen. 
© Für die Adaption vorhandener Programme auf andere Systeme gibt MC 
aurch umfassende Dokumentation der rechnerinternen Betriebssoftware — 
die oft nicht einmal der Computer-Hersteller bietet - gezielte 
Anleitungen. 
% Programmierhilfen: Als Software-Entwickler hilft Ihnen MC, Zeit und 
Gald zu sparen mit Standard-Routinen, Hilfsprogrammen, Softwarekniffen 
und Hinweisen zu Betriebssystem-Erweiterungen. 
© Hardware-Tips: MC hilft Ihnen bei der Entwicklung und beim Bau 
individueller Hardware-Bausteine: Einplatinen-Mikrocomputer, Speicher- 
Erweiterungen, Interface-Schaltungen - kurz alles, was man eben doch 
selber machen muß. 
® Software-Informationen: MC berichtet über neue Programmpakete, 
gibt Übersichten über Programmiersprachen und Betriebssysteme. 
In Grundlagenbeiträgen werden die logischen Zusammenhänge des 
Programmierens geschildert. 
© Grundlagenbeiträge über Arbeitsweise und Eigenschaften von Mikro- 
computern und Peripherie. 
© Wie denken Computer? MC zeigt Ihnen, wie Ihr Tischcomputer intern 
„denkt“. Das ermöglicht Ihnen, Ihr Gerät noch besser auszunutzen. 


Die Mikrocompute 


Ein Abonnement können Sie hier oder bei jeder 
. Buchhandlung bestellen! 


| 





Bestellkarte Bestellkarte 


für ein Abonnement, Sonderheft oder Probeheft für ein Abonnement, Sonderheft oder Probeheft 











regelmäßig die Zeitschrift 


aD 


12 Hefte pro Jahr, Jahresabonnementspreis 
39.60 DM im Inland, im Ausland 48.- DM 


mu un, 


Bitte senden Sie ab 


26 Hefte pro Jahr, Jahresabonnementspreis 
115.20 DM im Inland, im Ausland 138.- DM. 


DL Funkschau 


regelmäßig die Zeitschrift 


DD 


12 Hefte pro Jahr, Jahresabonnementspreis 
39.60 DM im Inland, im Ausland 48.- DM N 


BE 5 5 — 


Bitte senden Sie ab 


U] Elektronik 


26 Hefte pro Jahr, Jahresabonnementspreis 
115.20 DM im Inland, im Ausland 138.- DM 


U Funkschau 





26 Hefte pro Jahr, Jahresabonnementspreis 
96.- DM im Inland, im Ausland 118.80 DM. 


12 Hefte pro Jahr, Jahresabonnementspreis 
60.- DM im Inland, im Ausland 66.- DM 


26 Hefte pro Jahr, Jahresabonnementspreis 
96.- DM im Inland, im Ausland 118.80 DM. 








Name/Vorname 





Beruf 





Straße 





PLZ/Ort 


Datum Unterschrift 


In den genannten Abonnementspreisen sind sämtliche Nebenkosten, einschließlich Porto, 
enthalten. Bei verlagsseitiger Änderung muß die Berechnung aus gesetzlichen Gründen 


(Preisbindung!) zum neuen Preis erfolgen. 


Die Kündigung ist jeweils 8 Wochen zum Kalenderjahresende möglich. 


Die Abonnementsgebühr ist nach Erhalt der Rechnung fällig. Preise Stand 10/82. Falls Sie 
Abbuchung vom Konto wünschen, beachten Sie bitte die Rückseite. Diese Vereinbarung 
können Sie innerhalb einer Woche schriftlich widerrufen. 
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Name/Vorname 


12 Hefte pro Jahr, Jahresabonnementspreis 
60.- DM im Inland, im Ausland 66.- DM. 





Beruf 


Straße 





PLZ/Ort 


Datum Unterschrift 


In den genannten Abonnementspreisen sind sämtliche Nebenkosten, einschließlich Porto, 
enthalten. Bei verlagsseitiger Änderung muß die Berechnung aus gesetzlichen Gründen 


(Preisbindung!) zum neuen Preis erfolgen. 


Die Kündigung ist jeweils 8 Wochen zum Kalenderjahresende möglich. 

Die Abonnementsgebühr ist nach Erhalt der Rechnung fällig. Preise Stand 10/82. Falls Sie 
Abbuchung vom Konto wünschen, beachten Sie bitte die Rückseite. Diese Vereinbarung 
können Sie innerhalb einer Woche schriftlich widerrufen. 
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In den letzten Jahren haben Mikroprozessoren die Elek- Mit unseren Sonderheften wollen wir jeden Elektroniker 
tronik revolutionär verändert. Und.doch steht die Entwick- oder Software-Spezialisten aktuell über den neuesten 





lung vor allem im Anwendungsbereich erst am Anfang. Stand informieren. Welches Heft für Sie als Informations- 
Eines aber ist absehbar: Jeder, der auch nur am Rande quelle in Frage kommt, können Sie aus nachstehender 
mit Elektronik zu tun hat, wird davon berührt werden. Tabelle ersehen. 

ELO-Sonderheft mc-Sonderheft FUNKSCHAU-Sonderheft 

Vom Bit zum Beispiel DAS EMUF-SONDERHEFT HOBBYCOMPUTER 2 


Aufbau, Programmierung Ba 2 Basic- und Maschinen- 
und Anwendung eines programme, 
Einplatinen-Mikro- Hardware-Tips. 
computers für universelle dojıp zutrrdy 

Festprogramm- 


Anwendung. nn [>7:) 


Bu 


Anwendungsbeispiele 
mit dem 
Mikrocomputer- 
System UMS-85. 


Überwiegend 


Ausschließlich exklusive | 
neue Beiträge. i 


Gesammelte Beiträge 
Beiträge. 


der in der ELO 
bereits erschienenen 
Fortsetzungsreihe. 


Für hardwareorientierte 
Mikrocomputer- 
Anwender (8085- 
CPU), auch Anfänger. 


Für Anfänger und 
Fortgeschrittene, 

6502-Assembler- 
Programmierung. 





Für Fortgeschrittene. 





56 Seiten, 12,— DM 67 Seiten, 17,— DM 80 Seiten, 14,— DM 
FUNKSCHAU-Sonderheft "ELEKTRONIK-Sonderheft ELEKTRONIK-Sonderheft 
mikrocomputer-anwendungen PASCAL Software-Werkzeuge 

Er Programme in Basic, Ey“ Grundlagen, Program- Werkzeuge, mit deren 


Hilfe die Produktion von 
Software in das Stadium 
der Automatisierung 
treten kann 


Maschinensprache, miertechnik, Unter- 
Pascal und für Taschen- } schiede zu anderen 
rechner der HP- u. Programmiersprachen, 
und TI-Serien. Zrundlagen und Systeme Beschreibung 

von Systemen. 


Überwiegend bewährte 
Beiträge aus 
der ELEKTRONIK. 


Die Beiträge sind sonst 
nirgendwo erschienen. 


Überarbeitete Beiträge 
aus der ELEKTRONIK. 


Für Mikrocomputer- 
Entwickler 
und -Anwender. 


Für alle Computer- 
Besitzer und solche, die 
es werden wollen. 


80 Seiten, 15,60 DM 64 Seiten, 18,50 DM 112 Seiten, 21,- DM 





Für Mikrocomputer- 
Entwickler. 

















® ® Bitte haben Sie Verständnis, daß der Verlag Einzel- ® 
Wo Si t es iege hefte aus organisatorischen Gründen nur gegen Vor- ranzıs- & ag 
auszahlung liefern kann. Wir bitten Sie, in diesem Fall 
als Bestellung den genannten Betrag plus 2,— DM Karlstraße 37. 8000 München 2? 


© Porto auf unser Postscheckkonto München x a 
Sonderhefte ® Nr. 813 75-809 mit genauer Nennung des jeweiligen EEE IE N 


Titels zu überweisen, oder einen Scheck über diese Die Hefte erhalten Sie in der Schweiz auch beim 





Sie erhalten diese Hefte bei allen Bahnhofsbuch- Summe an uns einzusenden. Bitte vergessen Sie Verlaa Thali 5 PAR: 
\ handlungen, größeren Zeitschriftenverkaufsstellen, nicht, auf dem Zahlungsbeleg -., Druckschrift Ihre a s all BG, OHABARS Pilzen 
Buchhandlungen und Elektronik-Fachhändlern volle Anschrift anzugeben. Snfort nach Eingang der und in Österreich beim Fachbuch Center Erb, 
, oder direkt beim Franzis-Verlag. Zahlung senden wir Ihnen d ıs Heft zu. A-1061 Wien, Amerlingstraße 1. 
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